[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <46109C88-01C8-40A1-B44B-B76BF8C119C7@dilger.ca>
Date: Thu, 26 Nov 2015 15:06:19 -0700
From: Andreas Dilger <adilger@...ger.ca>
To: David Howells <dhowells@...hat.com>
Cc: Christoph Hellwig <hch@...radead.org>, arnd@...db.de,
linux-afs@...r.kernel.org, linux-nfs@...r.kernel.org,
linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-ext4@...r.kernel.org
Subject: Re: [RFC][PATCH 00/12] Enhanced file stat system call
On Nov 26, 2015, at 8:19 AM, David Howells <dhowells@...hat.com> wrote:
>
> Christoph Hellwig <hch@...radead.org> wrote:
>
>> from a quick look the statx bits looks fine in general. I think Ted
>> last time had a problem with the IOC flag allocation, so you might
>> want to ping him.
>
> Yeah - he commented on that.
>
>> But fsinfo with the multiplexer and the void pointer is just horrible.
>> What were you thinking there?
>
> I think the fsinfo data struct probably wants splitting up.
Could we separate the statx() and fsinfo() submissions so that this doesn't
block statx() landing indefinitely? I think people are generally in support
of statx() as it is today, and it's been _sooo_ long in coming that I'd hate
to see it delayed further. The statx() syscall definitely has value without
fsinfo() to improve the life of network filesystems.
Cheers, Andreas
> Now this could be
> done in a number of ways, including:
>
> (1) By adding multiple syscalls (statfsx, fsinfo, netfsinfo, ...) but each
> one needs a bit in the kernel to handle the basics (path/fd lookup,
> security check, buffer allocation and freeing, ...) which could all be in
> common - hence the mux method.
>
> (2) Adding an argument to the fsinfo syscall since it has at least one
> syscall argument spare.
>
> (3) Offloading some of the bits to standardised xattr calls. The large
> string fields (domain name, volume name, ...) would seem to be obvious
> candidates for this.
>
> Given that the core VFS gets to manage the contents of the buffer, it
> shouldn't be as controversial as pioctl().
>
> David
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers, Andreas
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists