From: Mingming <cmm@us.ibm.com>
To: Andreas Dilger <adilger@sun.com>
Cc: Steve French <smfrench@gmail.com>, jim owens <jowens@hp.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
samba-technical <samba-technical@lists.samba.org>
Subject: Re: ext4 - getting at birth time (file create time) and getting/setting nanosecond time stamps and utime
Date: Wed, 21 Oct 2009 16:42:39 -0700 [thread overview]
Message-ID: <1256168559.6404.14.camel@mingming-laptop> (raw)
In-Reply-To: <0D2A558D-C332-4C82-999A-A29B740C2008@sun.com>
On Tue, 2009-10-20 at 18:44 -0600, Andreas Dilger wrote:
> On 20-Oct-09, at 14:49, Steve French wrote:
> > On Tue, Oct 20, 2009 at 3:33 PM, Andreas Dilger <adilger@sun.com>
> > wrote:
> >> For those users/admins that want to be able to change this (due to
> >> Samba, or whatever), great, we can give them this ability, but for
> >> users who do NOT want regular users to be able to change the file
> >> creation timestamp, that should be possible as well.
> >
> > So, are we ready for Mingming or one of the ext4 developers to propose
> > a patch for this via xattrs (I can do a similar one for cifs).
> > Sounds like various have said:
> >
> > 1) xattrs instead of ioctl
> > 2) get of create time allowed by default, but set of create time
> > limited
>
>
> A wildly untested/uncompiled patch is attached for purposes of
> discussion.
> One issue that I've already come across is if we are storing a raw
> "timespec"
> we will get different xattrs on disk in the fallback case where the on-
> disk
> inodes are not large enough to store the crtime inside the inode.
>
> This version of the patch will fall back to storing the timespec on disk
> in the supplied size/endianness as an xattr, but it definitely needs
> to be
> handled more appropriately (endian/word size). It _would_ be nice to
> store
> a full 64-bit timespec on disk, but given that the in-inode format
> only can
> handle 34 bits of seconds + 30 bits of nanoseconds, it isn't clear
> whether
> the "fallback" should do better than that.
>
Could we transparently convert user provided raw creation time and store
the same format as whose in-inode creation timestamp in the fallback
case? Just to be consistent. User doesn't have to know what type/size of
ext4 inode it is accessing...
> The main question is whether storing a "user.crtime" as an on-disk xattr
> is a desirable fallback, or if this should just fail?
I think it would be nice to have this fallback, just be consistent, that
for all type of ext4 inodes there is a way to set file creation time for
allowed users(whether default 256 bytes large inode which could store
the 34+30bit creation time, or the 128 bytes smaller inode, which
doesn't have space to store the creation in the inode)
Regards,
Mingming
> Similarly, should
> the lack of on-disk crtime return "0.0" as the creation time, or should
> it return -ENODATA or similar?
> Cheers, Andreas
> --
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, Inc.
next prev parent reply other threads:[~2009-10-21 23:45 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-19 17:17 ext4 - getting at birth time (file create time) and getting/setting nanosecond time stamps and utime Steve French
2009-10-19 18:55 ` Andreas Dilger
2009-10-19 18:58 ` Jeremy Allison
2009-10-19 19:37 ` Steve French
2009-10-19 19:12 ` Zach Brown
2009-10-19 20:49 ` Jamie Lokier
2009-10-19 19:45 ` Steve French
2009-10-19 20:11 ` Andreas Dilger
2009-10-19 22:24 ` Steve French
2009-10-19 23:12 ` Andreas Dilger
2009-10-20 3:31 ` Steve French
2009-10-20 12:44 ` jim owens
2009-10-20 20:33 ` Andreas Dilger
2009-10-20 20:49 ` Steve French
2009-10-20 20:59 ` Sunil Mushran
2009-10-20 21:11 ` Steve French
2009-10-20 21:23 ` Sunil Mushran
2009-10-20 21:37 ` Steve French
2009-10-20 21:49 ` Sunil Mushran
2009-10-20 21:56 ` Steve French
2009-10-20 22:16 ` Sunil Mushran
2009-10-21 23:45 ` Mingming
2009-10-21 11:59 ` Henrik Nordstrom
2009-10-21 15:36 ` Steve French
2009-10-21 18:56 ` Brad Boyer
2009-10-21 23:03 ` Björn Jacke
2009-10-22 21:50 ` Steve French
2009-10-21 0:44 ` Andreas Dilger
2009-10-21 23:42 ` Mingming [this message]
2009-10-20 21:10 ` jim owens
2009-10-20 0:41 ` Mingming
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1256168559.6404.14.camel@mingming-laptop \
--to=cmm@us.ibm.com \
--cc=adilger@sun.com \
--cc=jowens@hp.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=samba-technical@lists.samba.org \
--cc=smfrench@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.