On 2012-04-26, at 6:51 PM, Dave Chinner wrote:
> On Thu, Apr 26, 2012 at 02:32:36PM +0100, David Howells wrote:
>> I wonder if there's a way to make this explicit - or is it something that if
>> the bit isn't set, you can't use the value in st_blksize.
>> I wonder if this value always has to be no
On Thu, Apr 26, 2012 at 02:32:36PM +0100, David Howells wrote:
> Andreas Dilger wrote:
> > st_blksize may be variable for a distributed filesystem,
It can be variable for local filesystems, too. XFS will vary the
block size based on the configuration of the inode. e.g. if there is
an extent alloc
On Thu, Apr 26, 2012 at 9:28 AM, J. Bruce Fields wrote:
> On Thu, Apr 26, 2012 at 02:45:54PM +0100, David Howells wrote:
>> 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
On Thu, Apr 26, 2012 at 02:45:54PM +0100, David Howells wrote:
> 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
On Thu, Apr 26, 2012 at 02:40:17PM +0100, David Howells wrote:
> 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*
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
On 2012-04-24, at 4:29 PM, J. Bruce Fields wrote:
> On Thu, Apr 19, 2012 at 03:06:12PM +0100, David Howells 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 w
On Tue, Apr 24, 2012 at 4:29 PM, J. Bruce Fields wrote:
> On Thu, Apr 19, 2012 at 03:06:12PM +0100, David Howells wrote:
>> Add a pair of system calls to make extended file stats available, including
>> file creation time, inode version and data version where available through
>> the
>> underlyin
On Thu, Apr 19, 2012 at 03:06:12PM +0100, David Howells wrote:
> Add a pair of system calls to make extended file stats available, including
> file creation time, inode version and data version where available through the
> underlying filesystem.
>
> The idea was initially proposed as a set of xat
On 2012-04-19, at 8:06 AM, David Howells wrote:
> Add a pair of system calls to make extended file stats available,
> including file creation time, inode version and data version where available
> through the underlying filesystem.
>
> The idea was initially proposed as a set of xattrs that could
Add a pair of system calls to make extended file stats available, including
file creation time, inode version and data version where available through the
underlying filesystem.
The idea was initially proposed as a set of xattrs that could be retrieved with
getxattr(), but the general preferance p
13 matches
Mail list logo
