On Thu, Jul 5, 2012 at 3:07 AM, Li Zefan <lizefan@xxxxxxxxxx> wrote: > On 2012/7/4 19:04, Alexander Block wrote: > >> On Wed, Jul 4, 2012 at 9:56 AM, Li Zefan <lizefan@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
