Dave Chinner wrote:
> st_blksize - file block size
> st_alloc_blksize- allocation block size/alignment
> st_small_io_size- IO size/alignment that avoids
> filesystem/page cache RMW
> st_preferred_io_size- pre
Dave Chinner wrote:
> If we are adding per-inode flags, then what do we do with filesystem specific
> flags? e.g. XFS has quite a number of per-inode flags that don't align with
> any other filesystem (e.g. filestream allocator, real time file, behaviour
> inheritence flags, etc), but may be usef
Andreas Dilger wrote:
> > However, since there is a remote file ID, we could add an
> > XSTAT_INFO_FILE_ID flag to indicate there's a standard xattr holding this.
>
> It is a bit strange that the kernel would return a flag that was not
> requested, but not fatal.
On the other hand, if it costs
Myklebust, Trond wrote:
> You are still not explaining why they need to know the values at all? If
> the values are bogus, then don't return them, and don't set the flag
> that says they are being returned.
What if the xstat() and struct xstat eventually becomes what userspace uses as
stat() (as
Roland McGrath wrote:
> > I've no particular attachment to the name 'xstat'. If you'd prefer
> > 'statx' I could go for that.
>
> I prefer something other than xstat and statx(at) seems acceptable enough.
> What I'd really prefer is a name that is less meaninglessly arcane,
> but I haven't thou
Steve French wrote:
> >> Would it be better to make the stable vs volatile inode number an attribute
> >> of the volume or something returned by the proposed xstat?
> >
> > I'm not sure what you mean by a stable vs a volatile inode number.
>
> Both NFS and CIFS (and SMB2) can return inode number
Myklebust, Trond wrote:
> Hmm... As far as I can see you are still doing an nfs_revalidate_inode()
> in the non-forced case. That will cause expired attributes to be
> retrieved from the server.
Revalidation is only done when you force it or explicitly ask for a basic stat
or the data version nu
Steve French wrote:
> Would it be better to make the stable vs volatile inode number an attribute
> of the volume or something returned by the proposed xstat?
I'm not sure what you mean by a stable vs a volatile inode number.
> > Should things like the Windows Archive, Hidden and System bits b
Roland McGrath wrote:
> statx seems like a better family of names. I also think it's worthwhile to
> see if the interface can be made to more closely match the AIX precedent.
I'm not sure we can make Linux xstat (or whatever) match AIX statxat() very
closely, at least from a syscall interface p
Paul Eggert wrote:
> On 04/19/2012 09:32 AM, Roland McGrath wrote:
> > I have no comment on the functionality. But "xstat" is probably a poor
> > choice of name.
>
> In AIX 7.1 the (similar) function is called statxat instead of xstat.
> The API isn't exactly the same, but it's the same basic
Roland McGrath wrote:
> I have no comment on the functionality. But "xstat" is probably a poor
> choice of name. There is precedent for that function name with different
> meaning in the userland APIs. (It's a moderately useless meaning inherited
> from SVR4, but regardless overloading a name
Steve French wrote:
> This patch reminds me of a question on time stamps - how can an
> application query the time granularity ie sb_s_time_gran for a mount
> (e.g. 1 second for some file systems, 100 nanoseconds for cifs/smb2, 1
> nanosecond for others etc.)
Ummm... In what context? With the
Steve French wrote:
> I also would prefer that we simply treat the time granularity as part
> of the superblock (mounted volume) ie returned on fstat rather than on
> every stat of the filesystem. For cifs mounts we could conceivably
> have different time granularity (1 or 2 second) on mounts t
J. Bruce Fields wrote:
> > (11) Include granularity fields in the time data to indicate the
> > granularity of each of the times (NFSv4 time_delta) [Steve French].
>
> It looks like you're including this with *each* time? But surely
> there's no filesystem with different granularity (say)
Andreas Dilger wrote:
> > The idea was initially proposed as a set of xattrs that could be
> > retrieved with getxattr(), but the general preferance proved to be
> > for new syscalls with an extended stat structure.
>
> I would comment that it was the opposite. It was originally a
> stat()-like
system
calls to be wired up.
===
TESTING
===
The following test program can be used to test the xstat system call:
/* Test the xstat() system call
*
* Copyright (C) 2010 Red Hat, Inc. All Rights Reserved.
* Written by David Howells (dhowe...@redhat.com)
directories have ACLs (the UID and GID
are only used through the ACLs) and these ACLs apply to the contents of
the directories.
Signed-off-by: David Howells
---
fs/afs/inode.c | 29 +
fs/afs/super.c |7 +++
2 files changed, 28 insertions(+), 8 deletions
L_INFO in addition to the FILE_UNIX_BASIC_INFO if it needs to collect
creation time and attributes on behalf of cifs_getattr().
[NOTE: THIS PATCH IS UNTESTED!]
Signed-off-by: David Howells
---
fs/cifs/cifsfs.h |4 +-
fs/cifs/cifsglob.h | 16 +--
fs/cifs/dir.c |2 -
ll be used - even if expired -
without reference to the server.
Signed-off-by: David Howells
---
fs/nfs/inode.c | 49 +
fs/nfs/super.c |1 +
2 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/fs/nfs/inode.c b/fs/nfs/in
Return extended attributes from the eCryptFS filesystem, dredged up from the
lower filesystem. XSTAT_INFO_ENCRYPTED is set on the files whose cryptography
is handled by eCryptFS.
Possibly eCryptFS should also set FS_COMPR_FL on its compressed files.
Signed-off-by: David Howells
---
fs
.
(4) FS_xxx_FL flags are returned as for ioctl(FS_IOC_GETFLAGS).
Signed-off-by: David Howells
---
fs/ext4/ext4.h|2 ++
fs/ext4/file.c|2 +-
fs/ext4/inode.c | 32 +---
fs/ext4/namei.c |2 ++
fs/ext4/super.c |1 +
fs/ext4/symlink.c |2
ID: 82fd1e71d4eb4959-80e3d5155c0b25d3
David
---
David Howells (6):
xstat: eCryptFS: Return extended attributes
xstat: CIFS: Return extended attributes
xstat: NFS: Return extended attributes
xstat: AFS: Return extended attributes
xstat: Ext4: Return extended attributes
xstat:
22 matches
Mail list logo
