ZFS should support statx(), at least for btime #8507

rlaager · 2019-03-16T23:52:06Z

Linux finally added a statx() syscall in 4.11 that can return btime ("birth time") aka crtime ("creation time"). glibc added support in 2.28. coreutils has support for statx() in master, as of two weeks ago. ZoL doesn't currently set btime in its getattr() responses as far as I can tell from the code.

If I'm following this correctly, it needs to do something like this in zfs_getattr_fast():

sp->result_mask |= STATX_BTIME;
sp->btime.tv_sec = ...
sp->btime.tv_nsec = ...

Besides btime, stat->attributes_mask has STATX_ATTR_COMPRESSED, STATX_ATTR_IMMUTABLE, STATX_ATTR_APPEND, STATX_ATTR_NODUMP, and STATX_ATTR_ENCRYPTED, most of which are the same as the FS_FL flags. ZFS doesn't currently set FS_ENCRYPT_FL flags, it seems, but it does set the other FS_FL in __zpl_ioctl_getflags().

It looks like STATX_ATTR_COMPRESSED has no FS_*_FL equivalent?

The text was updated successfully, but these errors were encountered:

rlaager · 2019-03-16T23:52:34Z

@ryao has a patch in progress: https://bpaste.net/show/c1524d0f7d34

I pointed out, and he agreed, that it needs sp->result_mask |= STATX_BTIME;. See: https://bpaste.net/show/484398e157c8

ZFS has had support for file birth times since the beginning and calls it crtime internally. Linux originally only supported birth time via an ext4 specific hack, but since Linux 4.11, the statx syscall has supported it, so we are free to expose it. Signed-off-by: Richard Yao <ryao@gentoo.org> Closes openzfs#8507

Linux 4.11 added a new statx system call that allows us to expose crtime as btime. We do this by caching crtime in the znode to match how atime, ctime and mtime are cached in the inode. statx also introduced a new way of reporting whether the immutable, append and nodump bits have been set. It adds support for reporting compression and encryption, but the semantics on other filesystems is not just to report compression/encryption, but to allow it to be turned on/off at the file level. We do not support that. We could implement semantics where we refuse to allow user modification of the bit, but we would need to do a dnode_hold() in zfs_znode_alloc() to find out encryption/compression information. That would introduce locking that will have a minor (although unmeasured) performance cost. It also would be inferior to zdb, which reports far more detailed information. We therefore omit reporting of encryption/compression through statx in favor of recommending that users interested in such information use zdb. Signed-off-by: Richard Yao <ryao@gentoo.org> Closes openzfs#8507

ZFS has had support for file birth times since the beginning and calls it crtime internally. Linux originally only supported birth time via an ext4 specific hack, but since Linux 4.11, the statx syscall has supported it, so we are free to expose it. Signed-off-by: Richard Yao <ryao@gentoo.org> Closes openzfs#8507

ryao · 2019-03-17T01:10:02Z

The STATX_ATTR_COMPRESSED and STATX_ATTR_ENCRYPTED file attributes have a couple of problems.The first is that other filesystems appear to allow turning on/off compression via them, so we wouldn't be matching the expected semantics. The second is that even if we (ab)use them only to report compression/encryption, we need to take a hold on the dnode to look up whether compression or encryption is used, which adds locking. That seems unnecessarily expensive given that few users will ever use this feature and the ones that do will likely want to use zdb anyway because it reports more detailed information. We can easily implement support for the other attributes, but it might be best if we pass on implementing support for STATX_ATTR_COMPRESSED and STATX_ATTR_ENCRYPTED, at least until there is an actual user for them.

That said, I have implemented support for everything but STATX_ATTR_COMPRESSED and STATX_ATTR_ENCRYPTED in #8509.

ZFS has had support for file birth times since the beginning and calls it crtime internally. Linux originally only supported birth time via an ext4 specific hack, but since Linux 4.11, the statx syscall has supported it, so we are free to expose it. Signed-off-by: Richard Yao <ryao@gentoo.org> Closes openzfs#8507

Linux 4.11 added a new statx system call that allows us to expose crtime as btime. We do this by caching crtime in the znode to match how atime, ctime and mtime are cached in the inode. statx also introduced a new way of reporting whether the immutable, append and nodump bits have been set. It adds support for reporting compression and encryption, but the semantics on other filesystems is not just to report compression/encryption, but to allow it to be turned on/off at the file level. We do not support that. We could implement semantics where we refuse to allow user modification of the bit, but we would need to do a dnode_hold() in zfs_znode_alloc() to find out encryption/compression information. That would introduce locking that will have a minor (although unmeasured) performance cost. It also would be inferior to zdb, which reports far more detailed information. We therefore omit reporting of encryption/compression through statx in favor of recommending that users interested in such information use zdb. Signed-off-by: Richard Yao <ryao@gentoo.org> Closes openzfs#8507

rlaager · 2019-03-17T04:26:56Z

Ignoring compress/encrypt seems reasonable.

Linux 4.11 added a new statx system call that allows us to expose crtime as btime. We do this by caching crtime in the znode to match how atime, ctime and mtime are cached in the inode. statx also introduced a new way of reporting whether the immutable, append and nodump bits have been set. It adds support for reporting compression and encryption, but the semantics on other filesystems is not just to report compression/encryption, but to allow it to be turned on/off at the file level. We do not support that. We could implement semantics where we refuse to allow user modification of the bit, but we would need to do a dnode_hold() in zfs_znode_alloc() to find out encryption/compression information. That would introduce locking that will have a minor (although unmeasured) performance cost. It also would be inferior to zdb, which reports far more detailed information. We therefore omit reporting of encryption/compression through statx in favor of recommending that users interested in such information use zdb. Signed-off-by: Richard Yao <ryao@gentoo.org> Closes openzfs#8507

Linux 4.11 added a new statx system call that allows us to expose crtime as btime. We do this by caching crtime in the znode to match how atime, ctime and mtime are cached in the inode. statx also introduced a new way of reporting whether the immutable, append and nodump bits have been set. It adds support for reporting compression and encryption, but the semantics on other filesystems is not just to report compression/encryption, but to allow it to be turned on/off at the file level. We do not support that. We could implement semantics where we refuse to allow user modification of the bit, but we would need to do a dnode_hold() in zfs_znode_alloc() to find out encryption/compression information. That would introduce locking that will have a minor (although unmeasured) performance cost. It also would be inferior to zdb, which reports far more detailed information. We therefore omit reporting of encryption/compression through statx in favor of recommending that users interested in such information use zdb. Signed-off-by: Richard Yao <ryao@gentoo.org> Closes openzfs#8507 Signed-off-by: Richard Yao <ryao@gentoo.org>

Linux 4.11 added a new statx system call that allows us to expose crtime as btime. We do this by caching crtime in the znode to match how atime, ctime and mtime are cached in the inode. statx also introduced a new way of reporting whether the immutable, append and nodump bits have been set. It adds support for reporting compression and encryption, but the semantics on other filesystems is not just to report compression/encryption, but to allow it to be turned on/off at the file level. We do not support that. We could implement semantics where we refuse to allow user modification of the bit, but we would need to do a dnode_hold() in zfs_znode_alloc() to find out encryption/compression information. That would introduce locking that will have a minor (although unmeasured) performance cost. It also would be inferior to zdb, which reports far more detailed information. We therefore omit reporting of encryption/compression through statx in favor of recommending that users interested in such information use zdb. Signed-off-by: Richard Yao <ryao@gentoo.org> Closes openzfs#8507

Linux 4.11 added a new statx system call that allows us to expose crtime as btime. We do this by caching crtime in the znode to match how atime, ctime and mtime are cached in the inode. statx also introduced a new way of reporting whether the immutable, append and nodump bits have been set. It adds support for reporting compression and encryption, but the semantics on other filesystems is not just to report compression/encryption, but to allow it to be turned on/off at the file level. We do not support that. We could implement semantics where we refuse to allow user modification of the bit, but we would need to do a dnode_hold() in zfs_znode_alloc() to find out encryption/compression information. That would introduce locking that will have a minor (although unmeasured) performance cost. It also would be inferior to zdb, which reports far more detailed information. We therefore omit reporting of encryption/compression through statx in favor of recommending that users interested in such information use zdb. Signed-off-by: Richard Yao <ryao@gentoo.org> Closes openzfs#8507 Signed-off-by: Richard Yao <ryao@gentoo.org>

Linux 4.11 added a new statx system call that allows us to expose crtime as btime. We do this by caching crtime in the znode to match how atime, ctime and mtime are cached in the inode. statx also introduced a new way of reporting whether the immutable, append and nodump bits have been set. It adds support for reporting compression and encryption, but the semantics on other filesystems is not just to report compression/encryption, but to allow it to be turned on/off at the file level. We do not support that. We could implement semantics where we refuse to allow user modification of the bit, but we would need to do a dnode_hold() in zfs_znode_alloc() to find out encryption/compression information. That would introduce locking that will have a minor (although unmeasured) performance cost. It also would be inferior to zdb, which reports far more detailed information. We therefore omit reporting of encryption/compression through statx in favor of recommending that users interested in such information use zdb. Signed-off-by: Richard Yao <ryao@gentoo.org> Closes openzfs#8507

jaysonlarose · 2019-12-09T22:30:42Z

Sorry to bother, but I was wondering what the status of this was? I'd very much like some way of getting access to a file/inode's creation time under ZFS, and this seems like the easiest path forward, considering the statx() stx_btime attribute also works for ext4.

Alternatively, is there any other method of exposing a file's ZFS creation time in userspace? I've looked high and low for such a thing, but evidently my Google-fu is not up to the task...

--Jays

behlendorf · 2019-12-10T00:32:02Z

There is a PR open when implements this functionality #8509, but it needs a little polish before it can be merged. It would be great if someone wants to pick up this work. What's still required in described in this #8509 (comment).

digitalsignalperson · 2020-05-24T20:59:00Z

Being able to access btime will be useful. Can there be a way to mutate this? E.g. for backup tools? With ext4 there is a debugfs request like set_inode_field filename crtime <value> [0]

Noticed my ZFS datasets shared over samba cifs mounted show birth time with stat. Seems this may be implemented as a pseudo-xattr, user.cifs.creationtime [1]

Also noting cifs recently adding support to mutate this "user" creation time. [2] though I'm not sure how

5.6 kernel (module version 2.25, released 3/29/2020, 59 changesets)
Add support for fallocate mode 0 for non-sparse files. Allow setting owner info, DOS attributes, creation time from user space backup/restore tools.

Noting with #8509 it might be that the birth time reported by stat directly from a ZFS mount will differ from the birth time reported by stat from a CIFS mount of a ZFS dataset? Any foreseeable conflicts this could result in?

[0] https://stackoverflow.com/questions/29906359/how-can-i-set-file-creation-times-in-zfs

[1] https://superuser.com/questions/703768/is-there-really-no-way-in-linux-to-get-creation-time-for-files-on-cifs-smb-share

[2] https://wiki.samba.org/index.php/LinuxCIFSKernel

dletai · 2020-07-20T21:00:39Z

Alternatively, is there any other method of exposing a file's ZFS creation time in userspace?
--Jays

@jaysonlarose Suppose you want to know the btime (or crtime) of file foo in pool tank in dataset bar.

sudo zdb -dddd tank/bar $(stat --format '%i' /tank/bar/foo) | grep crtime

Credit to Joerg Moellenkamp @jmoekamp and https://gist.github.com/mbarczak/e595dbe54b98ce5a433d17c3e6889462

jaysonlarose · 2020-07-20T21:31:23Z

@dletai I did see that one from elsewhere on the Internet, unfortunately it requires root and a command execution to perform.

What I'm trying to do is manage a database of filesystem attributes (such as MIME type, sha512sum, various comparison hashes for images, that sort of thing. Kind of like Spotlight on Mac OS, except not), which I originally was using extended attributes for, except retrieving a few million xattrs is an order of magnitude slower than just pulling them from an SQLite database. I keyed the database to inode, which allows me to have my attributes follow the file across renames and hardlinks, but the problem I ran into is that I have no reliable way of determining whether or not any given inode has been deleted and reused (in which case I should remove the stale entries instead of allowing them to propagate to the new file).

On filesystems such as EXT4, I can get cheap and easy access to the file creation time via the statx syscall, which I can then compare against the database to decide whether or not to invalidate the data. I have an interim workaround for filesystems such as zfs that support xattrs but not statx birthtime, where I store the filesystem inode as an xattr. If the inode xattr doesn't match the actual inode number or (far more likely) it just plain goes away, I know that I need to invalidate the data.

dletai · 2020-10-02T14:54:30Z

@jaysonlarose Sounds like an object store would be a better match - have you considered CEPH? Or even manta since this is a ZFS space after all :)

almereyda · 2021-01-25T18:11:04Z

This year's release of Fedora 34 and Ubuntu 21.10 will include a change to Nautilus that allows for displaying the statx creation time, after merging the changes that resolved these issues:

The questions that arise here for me are:

Is it possible or likely that we will see some development efforts here that correlate with the planned changes at the other projects this year?
Is Canonical's OpenZFS team aware of this issue regarding the upcoming switch to GNOME 40 for desktop installations using the experimental ZFS support?

References:

Linux 4.11 added a new statx system call that allows us to expose crtime as btime. We do this by caching crtime in the znode to match how atime, ctime and mtime are cached in the inode. statx also introduced a new way of reporting whether the immutable, append and nodump bits have been set. It adds support for reporting compression and encryption, but the semantics on other filesystems is not just to report compression/encryption, but to allow it to be turned on/off at the file level. We do not support that. We could implement semantics where we refuse to allow user modification of the bit, but we would need to do a dnode_hold() in zfs_znode_alloc() to find out encryption/compression information. That would introduce locking that will have a minor (although unmeasured) performance cost. It also would be inferior to zdb, which reports far more detailed information. We therefore omit reporting of encryption/compression through statx in favor of recommending that users interested in such information use zdb. Signed-off-by: Richard Yao <ryao@gentoo.org> Closes openzfs#8507

digitalsignalperson · 2021-07-27T23:28:39Z

@freqlabs thanks for working on the PR. You mention in the description "Samba wants to know birthtime." so I wonder if you or anyone here might have any insight on what samba is doing when it currently reports crtime with statx for a given file over a share to a zfs filesystem

Currently my ZFS pools are on a linux server and I have samba shares for access from a workstation

on the server if I stat a file I can't see crtime, but can access a crtime with zdb
on the workstation mounting a samba share to access the same file, using stat does report a crtime

I thought samba might be using some xattrs to be storing a crtime seperately, but I don't see any. Furthermore The crtime I see through the samba mount is not always consistent with the crtime I see on the server using zdb, so I'm not sure how it works

Examples

Scenario 1: samba crtime differs from zdb crtime

on server, stat a file x.txt on the zfs mount

Access: 2019-09-15 22:13:38.338744793 -0700
Modify: 2009-01-02 19:20:14.000000000 -0800
Change: 2019-09-15 22:13:38.338744793 -0700
Birth: -

using zdb instead

atime   Sun Sep 15 22:13:38 2019
mtime   Fri Jan  2 19:20:14 2009
ctime   Sun Sep 15 22:13:38 2019
crtime  Sun Sep 15 22:13:38 2019

on workstation, stat the same x.txt through the samba mount

Access: 2019-09-15 22:13:38.338744700 -0700
Modify: 2009-01-02 19:20:14.000000000 -0800
Change: 2009-01-02 19:20:14.000000000 -0800
Birth: 2009-01-02 19:20:14.000000000 -0800

Samba's showing the birth time and change time as 2009, differing from the "true" values per zdb. Aside: the 2009 birth time is the "intuitive" one to me, as that is when the original file was created. This is what I see on my workstation through stat and visible in file managers in the "Created" column (e.g. Dolphin). Originally I used robocopy on windows to copy and preserve the timestamps when copying to these shares.

Scenario 2: samba crtime equals zdb crtime

on server, stat a file y.txt on the zfs mount

Access: 2020-10-23 19:56:27.000000000 -0700
Modify: 2020-10-23 19:56:27.000000000 -0700
Change: 2021-04-27 17:12:02.943113079 -0700
Birth: -

using zdb instead

atime   Fri Oct 23 19:56:27 2020
mtime   Fri Oct 23 19:56:27 2020
ctime   Tue Apr 27 17:12:02 2021
crtime  Tue Apr 27 17:12:01 2021

on workstation, stat the same y.txt through the samba mount

Access: 2020-10-23 19:56:27.000000000 -0700
Modify: 2020-10-23 19:56:27.000000000 -0700
Change: 2020-10-23 19:56:27.000000000 -0700
Birth: 2021-04-27 17:12:01.852107300 -0700

This time, samba and zdb seem to agree for birth/crtime, and still disagree for change/ctime.

Cheers for anyone reading this far. Just curious how I might consider managing creation time or not going forward. Seemingly right now as-is on samba shares I can use windows tools like robocopy to preserve creation date (e.g. that's where the 2009 came from) still with zfs backed shares.

rlaager · 2021-07-27T23:38:59Z

@digitalsignalperson I suspect that Samba is just using the earliest of the values it sees (since there is no real crtime coming back from statx()). AFAIK, there is no way to set crtime, so if you are restoring files, they will get a newer crtime.

digitalsignalperson · 2021-07-28T01:14:08Z

@rlaager using the earliest date conflicts with scenario 2 (real example) where samba reports the birth time as 2021-04-27, and the earliest time is the mtime 2020-10-23

ghost · 2021-07-28T03:47:46Z

Just a guess, but Samba could be using some user xattr to keep track of it separately. @anodos325 might know what is actually going on there.

digitalsignalperson · 2021-07-28T04:55:11Z

Hmm right, it's probably in this user.DOSATTRIB

On the first file getfattr --dump -m - x.txt shows nothing, but the 2nd getfattr --dump -m - y.txt shows a user.DOSATTRIB.

here https://wiki.samba.org/index.php/LinuxCIFSKernel it says under 4.9 Kernel

Add way to query file attributes (cifs.dosattrib) and creation time (cifs.creationtime) via Linux xattrs

Googling seeing some suggest that creation time is stored in user.DOSATTRIB, but not sure how to decode it. That probably explains it though. Anyway, maybe off topic at this point.

Also agree, don't think there's a away to modify the zfs crtime. Some old discussion here with no solution https://stackoverflow.com/questions/29906359/how-can-i-set-file-creation-times-in-zfs

jaysonlarose · 2021-07-28T12:13:34Z

@dletai Sorry for the delay in replying... since I'm working with files on a file system, I'd prefer it if I could just be able to use the file birth time, like I can do with ext3.

@digitalsignalperson @freqlabs Interesting that samba is using an extended filesystem attribute to store that data. I guess it's a good way to do things if you can't get at the birth time through conventional means: It'll survive renames and hardlinks, and won't survive if the inode is unlinked and subsequently recycled. I was thinking of doing the same thing for my own implementation, (specifically by dropping something like a uuid4 into an extended attribute), but I've never bothered moving off ext3, because hey, birth time.

digitalsignalperson · 2021-07-28T20:22:57Z

With ext4 you can use debugfs set_inode_field filename crtime <value> to change crtime. Would zdb or any particular zfs tool be appropriate to consider implementing something similar?

Linux 4.11 added a new statx system call that allows us to expose crtime as btime. We do this by caching crtime in the znode to match how atime, ctime and mtime are cached in the inode. statx also introduced a new way of reporting whether the immutable, append and nodump bits have been set. It adds support for reporting compression and encryption, but the semantics on other filesystems is not just to report compression/encryption, but to allow it to be turned on/off at the file level. We do not support that. We could implement semantics where we refuse to allow user modification of the bit, but we would need to do a dnode_hold() in zfs_znode_alloc() to find out encryption/compression information. That would introduce locking that will have a minor (although unmeasured) performance cost. It also would be inferior to zdb, which reports far more detailed information. We therefore omit reporting of encryption/compression through statx in favor of recommending that users interested in such information use zdb. Signed-off-by: Richard Yao <ryao@gentoo.org> Closes openzfs#8507

Linux 4.11 added a new statx system call that allows us to expose crtime as btime. We do this by caching crtime in the znode to match how atime, ctime and mtime are cached in the inode. statx also introduced a new way of reporting whether the immutable, append and nodump bits have been set. It adds support for reporting compression and encryption, but the semantics on other filesystems is not just to report compression/encryption, but to allow it to be turned on/off at the file level. We do not support that. We could implement semantics where we refuse to allow user modification of the bit, but we would need to do a dnode_hold() in zfs_znode_alloc() to find out encryption/compression information. That would introduce locking that will have a minor (although unmeasured) performance cost. It also would be inferior to zdb, which reports far more detailed information. We therefore omit reporting of encryption/compression through statx in favor of recommending that users interested in such information use zdb. Reviewed-by: Tony Nguyen <tony.nguyen@delphix.com> Reviewed-by: Allan Jude <allan@klarasystems.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Alexander Motin <mav@FreeBSD.org> Reviewed-by: Ryan Moeller <ryan@iXsystems.com> Signed-off-by: Richard Yao <ryao@gentoo.org> Closes openzfs#8507

Linux 4.11 added a new statx system call that allows us to expose crtime as btime. We do this by caching crtime in the znode to match how atime, ctime and mtime are cached in the inode. statx also introduced a new way of reporting whether the immutable, append and nodump bits have been set. It adds support for reporting compression and encryption, but the semantics on other filesystems is not just to report compression/encryption, but to allow it to be turned on/off at the file level. We do not support that. We could implement semantics where we refuse to allow user modification of the bit, but we would need to do a dnode_hold() in zfs_znode_alloc() to find out encryption/compression information. That would introduce locking that will have a minor (although unmeasured) performance cost. It also would be inferior to zdb, which reports far more detailed information. We therefore omit reporting of encryption/compression through statx in favor of recommending that users interested in such information use zdb. Reviewed-by: Tony Nguyen <tony.nguyen@delphix.com> Reviewed-by: Allan Jude <allan@klarasystems.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Alexander Motin <mav@FreeBSD.org> Reviewed-by: Ryan Moeller <ryan@iXsystems.com> Signed-off-by: Richard Yao <ryao@gentoo.org> Closes #8507

Linux 4.11 added a new statx system call that allows us to expose crtime as btime. We do this by caching crtime in the znode to match how atime, ctime and mtime are cached in the inode. statx also introduced a new way of reporting whether the immutable, append and nodump bits have been set. It adds support for reporting compression and encryption, but the semantics on other filesystems is not just to report compression/encryption, but to allow it to be turned on/off at the file level. We do not support that. We could implement semantics where we refuse to allow user modification of the bit, but we would need to do a dnode_hold() in zfs_znode_alloc() to find out encryption/compression information. That would introduce locking that will have a minor (although unmeasured) performance cost. It also would be inferior to zdb, which reports far more detailed information. We therefore omit reporting of encryption/compression through statx in favor of recommending that users interested in such information use zdb. Reviewed-by: Tony Nguyen <tony.nguyen@delphix.com> Reviewed-by: Allan Jude <allan@klarasystems.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Alexander Motin <mav@FreeBSD.org> Reviewed-by: Ryan Moeller <ryan@iXsystems.com> Signed-off-by: Richard Yao <ryao@gentoo.org> Closes openzfs#8507

ryao mentioned this issue Mar 17, 2019

Linux 4.11 compat: statx support #8509

Closed

12 tasks

bunder2015 added the Missing Template label Mar 18, 2019

behlendorf added Type: Feature Feature request or new feature and removed Missing Template labels Mar 19, 2019

adamdmoss mentioned this issue Jul 26, 2021

Linux 4.11 compat: statx support #12432

Closed

13 tasks

behlendorf closed this as completed in abbf0bd Aug 17, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ZFS should support statx(), at least for btime #8507

ZFS should support statx(), at least for btime #8507

rlaager commented Mar 16, 2019 •

edited

Loading

rlaager commented Mar 16, 2019 •

edited

Loading

ryao commented Mar 17, 2019

rlaager commented Mar 17, 2019

jaysonlarose commented Dec 9, 2019

behlendorf commented Dec 10, 2019

digitalsignalperson commented May 24, 2020

dletai commented Jul 20, 2020 •

edited

Loading

jaysonlarose commented Jul 20, 2020

dletai commented Oct 2, 2020

almereyda commented Jan 25, 2021 •

edited

Loading

digitalsignalperson commented Jul 27, 2021

rlaager commented Jul 27, 2021

digitalsignalperson commented Jul 28, 2021

ghost commented Jul 28, 2021

digitalsignalperson commented Jul 28, 2021

jaysonlarose commented Jul 28, 2021

digitalsignalperson commented Jul 28, 2021

ZFS should support statx(), at least for btime #8507

ZFS should support statx(), at least for btime #8507

Comments

rlaager commented Mar 16, 2019 • edited Loading

rlaager commented Mar 16, 2019 • edited Loading

ryao commented Mar 17, 2019

rlaager commented Mar 17, 2019

jaysonlarose commented Dec 9, 2019

behlendorf commented Dec 10, 2019

digitalsignalperson commented May 24, 2020

dletai commented Jul 20, 2020 • edited Loading

jaysonlarose commented Jul 20, 2020

dletai commented Oct 2, 2020

almereyda commented Jan 25, 2021 • edited Loading

digitalsignalperson commented Jul 27, 2021

Examples

rlaager commented Jul 27, 2021

digitalsignalperson commented Jul 28, 2021

ghost commented Jul 28, 2021

digitalsignalperson commented Jul 28, 2021

jaysonlarose commented Jul 28, 2021

digitalsignalperson commented Jul 28, 2021

rlaager commented Mar 16, 2019 •

edited

Loading

rlaager commented Mar 16, 2019 •

edited

Loading

dletai commented Jul 20, 2020 •

edited

Loading

almereyda commented Jan 25, 2021 •

edited

Loading