Date: Wed, 22 Jun 2016 01:18:22 +0800 From: Julian Elischer <julian@freebsd.org> To: Kirk McKusick <mckusick@mckusick.com> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>, "'Jilles Tjoelker'" <jilles@stack.nl>, John Baldwin <jhb@freebsd.org> Subject: Re: futimens and utimensat vs birthtime (resurrected) Message-ID: <f886e8c7-fb0a-0881-a378-8ad7459ec9a2@freebsd.org> In-Reply-To: <56401002.8020909@freebsd.org> References: <201508142122.t7ELMPjR002452@chez.mckusick.com> <56401002.8020909@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
bringing this up again. see below for new info.. On 9/11/2015 11:16 AM, Julian Elischer wrote: > On 8/15/15 5:22 AM, Kirk McKusick wrote: >>> From: John Baldwin <jhb@freebsd.org> >>> To: freebsd-current@freebsd.org >>> Subject: Re: futimens and utimensat vs birthtime >>> Date: Fri, 14 Aug 2015 10:39:41 -0700 >>> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>, >>> "'Jilles Tjoelker'" <jilles@stack.nl> >>> >>> On Friday, August 14, 2015 10:46:10 PM Julian Elischer wrote: >>>> I would like to implement this call. but would like input as to it's >>>> nature. >>>> The code inside the system would already appear to support handling >>>> three elements, though it needs some scrutiny, >>>> so all that is needed is a system call with the ability to set the >>>> birthtime directly. >>>> >>>> Whether it should take the form of the existing calls but expecting >>>> three items is up for discussion. >>>> Maybe teh addition of a flags argument to specify which items are >>>> present and which to set. >>>> >>>> ideas? >>> I believe these should be new calls. Only utimensat() provides a >>> flag >>> argument, but it is reserved for AT_* flags. I would be fine with >>> something like futimens3() and utimensat3() (where 3 means "three >>> timespecs"). Jilles implemented futimens() and utimensat(), so he >>> might have ideas as well. I would probably stick the birth time in >>> the third (final) timespec slot to make it easier to update new code >>> (you can use an #ifdef just around ts[2] without having to #ifdef the >>> entire block). >>> >>> -- >>> John Baldwin >> I concur with John's suggestion. Add a new system call with three >> argument set of times specifying birthtime as the last one. I >> proposed doing this when I added birthtime, but did not as the >> sentiment at the time was that it would gratuitously make FreeBSD >> written applications less portable if they used this new non-standard >> system call. > > time has passed and I would like to get back to this: > There was some feedback last time. Taking that into account: > > One problem with the '3 arg' version is that we have to reinvent it > again if we get a 4th. > We could make something like the following: > > It has been suggested that a 4th entry might be "last archive time" > and that > "time created on this filesystem" and "file created first time > (ever)" might also > be separate in some systems. (as examples of why 3 might not be enough) ok, so a real 4th arg has turned up it turns out that to be really compatible with windows servers and if you are running a filesystem capable of doing it.. then you need to be able to stamp the "change time". Apparently Windows does this an there are applications that require it. I believe that most filesystems would simply not do this but at $JOB we have our own FS and it CAN do this. we just need a way to interface to it. So now we have 4 real and a hypothetical timestamps. access time modification time birth/creation time change time (archive time) The filesystem would have to support changing ctime, and you'd have to have some other safeguards but does anyone have any comments on the example below? Does anyone know what people like netapp and panasas do? isilon? > > the syscall name is also not decided. (fsetnstimes()) > one suggested form is: > $name (int fd, int32 flags/mask, const struct timespec *arrayptr[]); > > vs the current: > utimensat(int fd, const char *path, const struct timespec times[2], > int flag); > > where mask is: > --- > 0x01 disable_heuristic > 0x02 AT_SYMLINK_NOFOLLOW > 0x04-0x08 unused > -- times present--- > 0x10 access time > 0x20 mod time > 0x40 birth time > 0x80 change time > 0x100 archive time > 0x200-on reserverd for future times > > any bit not set in 0x010-on is not represented in the array. > no bits would be a nop (the price for orthogonality) and would > effectively be the same as a test for writeability. > "disable heuristic" would disable the forcing of birthtime back to > mod time or earlier (and any other 'logical fixes') > setting all 5 'time-present' bits would imply the array has 5 entries. > > anyone care to comment ? >> >> Kirk McKusick >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f886e8c7-fb0a-0881-a378-8ad7459ec9a2>