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.
--
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
