On 2012/7/5 9:52, Alexander Block wrote: > On Thu, Jul 5, 2012 at 3:07 AM, Li Zefan <lize...@huawei.com> wrote: >> On 2012/7/4 19:04, Alexander Block wrote: >> >>> On Wed, Jul 4, 2012 at 9:56 AM, Li Zefan <lize...@huawei.com> wrote: >>>> On 2012/7/4 15:18, chandan r wrote: >>>> >>>>> This patch adds a new member to the 'struct btrfs_inode' structure to hold >>>>> the file creation time. >>>>> >>>> >>>> >>>> Well, how do users use this file creation time? There's no syscall and >>>> there's >>>> no ioctl that exports this information. That xstat syscall hasn't been >>>> accepted, >>>> so you can revise and repost the patch when you see it happens. >>> In my opinion we should still include this patch. Currently, otime is never >>> even >>> initialized, having undefined values. If it ever gets possible to >>> access otime, we >>> would at least have some inodes with valid otime fields. >> >> >> otime (on disk) is initialized to 0, not some undefined value. But yeah, >> your point makes >> some sense, that with this patch we can access valid otime in an old >> filesystem once we >> update to a new kernel which has otime support. > This is true for the inode items found in the root tree. But the inode > items found in the filesystem trees are not initialized at all. I did > a fast check by adding printing of the otime field in > btrfs-debug-tree...and every inode's otime looks random. > btrfs_new_inode uses btrfs_insert_empty_items which does not zero the > new item, then fill_inode_item is used to initialize the fields and > there otime is missing. >
That's bad.. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
