On 15/01/15 21:48, David Sterba wrote:
Chandan, please drop the btrfs_inode_otime helper and resend. Thanks.
Thanks!
Sorry I'd had no further time to look at this, I've been fully committed
with $DAY_JOB and on a number of projects with our local community
observatory (if anyone is in/visiting
On Fri, Jan 09, 2015 at 05:11:42PM +0100, David Sterba wrote:
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -5835,6 +5835,11 @@ static struct inode *btrfs_new_inode(struct
btrfs_trans_handle *trans,
sizeof(*inode_item));
fill_inode_item(trans,
Am Mittwoch, 7. Januar 2015, 06:42:50 schrieb Christoph Hellwig:
On Wed, Jan 07, 2015 at 02:57:35PM +0100, Lennart Poettering wrote:
Exposig this as xattr sounds great to me too.
NAK - exposing random stat data as xattr only creates problems.
Given that we don't seem to be able to get a
On Sat, Jan 10, 2015 at 11:13:52AM +0100, Martin Steigerwald wrote:
What is the issue with the xstat, new stat format stuff? Basically I have the
feeling that this is in discussion for at least 5 years or so and I always
wondered where it is stuck. I am not aware of any discussions of it
On Thu, Jan 08, 2015 at 09:52:30PM +1100, Chris Samuel wrote:
Sorry for the delay, took a while to poke around the code to figure
out possible ways it would get done (and what the right structure was).
No delay noticed :)
Set the otime in btrfs_new_inode after the call to fill_inode_item.
On Tue, 06.01.15 19:26, David Sterba (dste...@suse.cz) wrote:
(Of course, even without xstat(), I think it would be good to have an
unprivileged ioctl to query the otime in btrfs... the TREE_SEARCH
ioctl after all requires privileges...)
Adding this interface is a different question. I
On Tue, 6 Jan 2015 10:47:00 PM Chris Samuel wrote:
On Mon, 5 Jan 2015 06:21:52 PM Lennart Poettering wrote:
It should be easy to initialize it to the mtime when the inode is
first created...
This I agree with, well worth doing anyway.
I'll see if I can knock up a patch.
Sadly it
On Mon, 5 Jan 2015 06:21:52 PM Lennart Poettering wrote:
Is this on purpose, or simply an oversight?
The only hint I can see that it's deliberate is the comment in fs/btrfs/send.c
that says:
/* TODO Add otime support when the otime patches get into upstream */
However...
It should be easy
On Mon, Jan 05, 2015 at 06:21:52PM +0100, Lennart Poettering wrote:
btrfs' btrfs_inode_item structure contains a field for the birth time
of a file, .otime. This field could be quite useful, and I'd like to
make use of it. I can query it with the BTRFS_IOC_TREE_SEARCH ioctl
from userspace,
On Tue, Jan 06, 2015 at 11:43:22PM +1100, Chris Samuel wrote:
On Tue, 6 Jan 2015 10:47:00 PM Chris Samuel wrote:
On Mon, 5 Jan 2015 06:21:52 PM Lennart Poettering wrote:
It should be easy to initialize it to the mtime when the inode is
first created...
This I agree with, well
10 matches
Mail list logo
