Re: RFE: per-subvolume timestamp that is updated on every change to a subvolume

2015-01-06 Thread Qu Wenruo


 Original Message 
Subject: Re: RFE: per-subvolume timestamp that is updated on every 
change to a subvolume

From: Qu Wenruo quwen...@cn.fujitsu.com
To: Lennart Poettering lenn...@poettering.net, 
linux-btrfs@vger.kernel.org

Date: 2015年01月06日 14:02


 Original Message 
Subject: RFE: per-subvolume timestamp that is updated on every change 
to a subvolume

From: Lennart Poettering lenn...@poettering.net
To: linux-btrfs@vger.kernel.org
Date: 2015年01月06日 01:27

Heya!

I am looking for a nice way to query the overall last modification
timestamp of a subvolume. i.e. the most recent mtime of *any* file or
directory within a subvolume. Ideally, I think, there was a
btrfs_timespec field for this in struct btrfs_root_item, alas there
isn't afaics. Any chance this can be added?
In fact, btrfs_root_item contains one btrfs_inode_item, which contains 
the a/c/m/otime.

But not sure if it contains the time you need.

I'd better add acmotime output for inode_item in btrfs-debug-tree and 
try myself.


Thanks,
Qu

The value in acmotime of the inode_item in root_item is not used,
so it seems anyone can use it to record the acmotime for your purpose.

Thanks,
Qu


Or is there another workable way to query this value? Maybe determine
it from the current generation of a subvolume or so? Is that tracked?
Ideas?

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


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


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


RFE: per-subvolume timestamp that is updated on every change to a subvolume

2015-01-05 Thread Lennart Poettering
Heya!

I am looking for a nice way to query the overall last modification
timestamp of a subvolume. i.e. the most recent mtime of *any* file or
directory within a subvolume. Ideally, I think, there was a
btrfs_timespec field for this in struct btrfs_root_item, alas there
isn't afaics. Any chance this can be added?

Or is there another workable way to query this value? Maybe determine
it from the current generation of a subvolume or so? Is that tracked?
Ideas?

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


Re: RFE: per-subvolume timestamp that is updated on every change to a subvolume

2015-01-05 Thread Qu Wenruo


 Original Message 
Subject: RFE: per-subvolume timestamp that is updated on every change to 
a subvolume

From: Lennart Poettering lenn...@poettering.net
To: linux-btrfs@vger.kernel.org
Date: 2015年01月06日 01:27

Heya!

I am looking for a nice way to query the overall last modification
timestamp of a subvolume. i.e. the most recent mtime of *any* file or
directory within a subvolume. Ideally, I think, there was a
btrfs_timespec field for this in struct btrfs_root_item, alas there
isn't afaics. Any chance this can be added?
In fact, btrfs_root_item contains one btrfs_inode_item, which contains 
the a/c/m/otime.

But not sure if it contains the time you need.

I'd better add acmotime output for inode_item in btrfs-debug-tree and 
try myself.


Thanks,
Qu


Or is there another workable way to query this value? Maybe determine
it from the current generation of a subvolume or so? Is that tracked?
Ideas?

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


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