New nanosecond stat patch for 2.5.44
Move time_t members in struct stat to struct timespec and allow subsecond timestamps for files. Too big to post on the list, because it edits a lot of file systems and drivers in a straight forward way.
This is required for reliable "make" on fast computers.
File systems that support nsec storage are currently: XFS, JFS, NFSv3 (if the filesystem on the server supports it), VFAT (not quite nanosecond), CIFS (unit in 100ns which is above what linux supports), SMBFS (for newer servers)
This is proposed for 2.6.
Changes against the last version:
- Now always take xtime_lock when accessing the whole of xtime
- Port to 2.5.44
- New filesystems supported: CIFS, AFS
ftp://ftp.firstfloor.org/pub/ak/v2.5/nsec-2.5.44-1.bz2
-Andi
Re: New nanosecond stat patch for 2.5.44 - new patch II
Quoted 1 line
ftp://ftp.firstfloor.org/pub/ak/v2.5/nsec-2.5.44-1.bz2
This version unfortunately had some problems. I removed it now and replaced it with
ftp://ftp.firstfloor.org/pub/ak/v2.5/nsec-2.5.44-2.bz2
If you already got -1 please redownload.
Thank you,
-Andi
Quoted 10 lines · Andi Kleen
Move
time_tmembers in struct stat to struct timespec and allow subsecond timestamps for files. Too big to post on the list, because it edits a lot of file systems and drivers in a straight forward way.This is required for reliable "make" on fast computers.
File systems that support nsec storage are currently: XFS, JFS, NFSv3 (if the filesystem on the server supports it), VFAT (not quite nanosecond), CIFS (unit in 100ns which is above what linux supports), SMBFS (for newer servers)
Two notes I might make about this:
1) It would be good if it were possible to select this with a config option (I don't care which way the default goes), so that people who don't need/care about the increased resolution don't need the extra space in their inodes and minor extra overhead. To make this a lot easier to code, having something akin to the inode_update_time() which does all of the i_[acm]time updates as appropriate.
2) Updating i_atime based on comparing the nsec timestamp is going to be a killer. I think AKPM saw dramatic performance improvements when he changed the code to only do the update once/second, and even though you are "only" updating the atime if the times are different, in practise this will be always. Even without the "per superblock interval" you suggest we should probably only update the atime once a second (I don't think anything is keyed off such high resolution atimes, unlike make and mtime/ctime).
3) The fields you are usurping in struct stat are actually there for the Y2038 problem (when time_t wraps). At least that's what Ted said when we were looking into nsec times for ext2/3. Granted, we may all be using 64-bit systems by 2038... I've always thought 64 bits is much to large for time_t, so we could always use 20 or 30 bits for sub-second times, and the remaining bits for extending time_t at the high end, and mask those off for now, but that is a separate issue...
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
Followup to: <[email protected]> By author: Andreas Dilger <[email protected]> In newsgroup: linux.dev.kernel
Quoted 9 lines
3) The fields you are usurping in struct stat are actually there for the Y2038 problem (when
time_twraps). At least that's what Ted said when we were looking into nsec times for ext2/3. Granted, we may all be using 64-bit systems by 2038... I've always thought 64 bits is much to large fortime_t, so we could always use 20 or 30 bits for sub-second times, and the remaining bits for extendingtime_tat the high end, and mask those off for now, but that is a separate issue...
64-bit time_t is nice because you don't *ever* need to worry about overflow; it's capable of handling times on a galactic lifespan scale. It's overkill, of course, but it's the *right* kind of overkill.
We probably need to revamp struct stat anyway, to support a larger dev_t, and possibly a larger ino_t (we should account for 64-bit ino_t at least if we have to redesign the structure.) At that point I would really like to advocate for int64_t ts_sec and uint32_t ts_nsec and quite possibly a int32_t ts_taidelta to deal with leap seconds... I'd personally like struct timespec to look like the above everywhere.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Quoted 6 lines · H. Peter Anvin
We probably need to revamp struct stat anyway, to support a larger
dev_t, and possibly a largerino_t(we should account for 64-bitino_tat least if we have to redesign the structure.) At that point I would really like to advocate forint64_tts_secanduint32_tts_nsecand quite possibly aint32_tts_taideltato deal with leap seconds... I'd personally like struct timespec to look like the above everywhere.
For filesystems can we get away with just the 64-bit nanoseconds? By my calculations that gives something like 584 years--do we need to worry about files older than that?
Chris
Signature · 4 lines
Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: [email protected]
Quoted 11 lines · Chris Friesen
Quoted 6 lines · H. Peter Anvin
We probably need to revamp struct stat anyway, to support a larger
dev_t, and possibly a largerino_t(we should account for 64-bitino_tat least if we have to redesign the structure.) At that point I would really like to advocate forint64_tts_secanduint32_tts_nsecand quite possibly aint32_tts_taideltato deal with leap seconds... I'd personally like struct timespec to look like the above everywhere.For filesystems can we get away with just the 64-bit nanoseconds? By my calculations that gives something like 584 years--do we need to worry about files older than that?
1) The hard drive is only about 50 years old, so there aren't any files older than that at the moment:
http://www.mdhc.scu.edu/100th/reyjohnson.htm
2) This thing is unlikely to be a problem in our lifetimes, our grandchildren's lifetimes, or our great grandchildren's lifetimes (barring unforseen advances in active telomere reconstruction and a regenerative interpretation of DNA that somehow looks at it as a blueprint rather than a recipe).
3) If any current hardware or software is still in use in the year 2554, it will be seriously overdue for an upgrade.
Rob
Signature · 2 lines
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad, CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
Quoted 13 lines · H. Peter Anvin
Followup to: <[email protected]> By author: Andreas Dilger <[email protected]> In newsgroup: linux.dev.kernelQuoted 9 lines
3) The fields you are usurping in struct stat are actually there for the Y2038 problem (when
time_twraps). At least that's what Ted said when we were looking into nsec times for ext2/3. Granted, we may all be using 64-bit systems by 2038... I've always thought 64 bits is much to large fortime_t, so we could always use 20 or 30 bits for sub-second times, and the remaining bits for extendingtime_tat the high end, and mask those off for now, but that is a separate issue...
Quoted 4 lines
64-bit
time_tis nice because you don't *ever* need to worry about overflow; it's capable of handling times on a galactic lifespan scale. It's overkill, of course, but it's the *right* kind of overkill.
Indeed.
Quoted 7 lines
We probably need to revamp struct stat anyway, to support a larger
dev_t, and possibly a largerino_t(we should account for 64-bitino_tat least if we have to redesign the structure.) At that point I would really like to advocate forint64_tts_secanduint32_tts_nsecand quite possibly aint32_tts_taideltato deal with leap seconds... I'd personally like struct timespec to look like the above everywhere.
I basically agree but I suspect that filesystem writers will not be very happy if you want to use 16 bytes for each timestamp, especially when 8 of the bytes (the 32 high order bits from the second count and the TAI-UT offset) do not change very often. (besides that tv_nsec is defined as a long, i.e. 64 bit on 64 bit machines and _signed_ , stupid if you ask me but I digress).
The goal as I understand it is to avoid first the possibility of ambiguous timestamps, but then we have to be careful also not to break existing applications (although they already broken wrt leap seconds).
I don't know how to trim the highly repeated most significant bytes of the tv_sec field (it's probably file system specific), but 4 bytes can easily be shaved from the on-disk structure by packing the leap second information in the high order bits of the nsec field: since the number of nanoseconds per second is unlikely to ever need more than 30 bits to be encoded ;-), the 2 most significant bits can be used to encode inserted leap seconds. Actually 1 bit should be sufficient but some texts claim that up to 2 leap seconds can be inserted, this has however actually never happened AFAICT and I believe that NTP for example does not support 2 leap seconds in a row.
Converting this encoding to the format you suggest for stat(2) is trivial:
it only needs a table of leap seconds. I don't care whether it's in the kernel or in user space: it's small and grows slowly.
For now I have more problems with the fact that gettimeofday and friends do not properly handle leap seconds and lead to ambiguous timestamps. Once this problem (a real killer for astronomical data acquisition, leap seconds are infrequent but they are a problem) is solved, filesystems can be updated.
What could be important now is to mask the low 30 bits of the nsec field and declare the 2 MSB reserved so that no kernel is out in the wild that simply copies the full nsec field to user space.
Regards,
Gabriel.
Quoted 8 lines · Gabriel Paubert
I basically agree but I suspect that filesystem writers will not be very happy if you want to use 16 bytes for each timestamp, especially when 8 of the bytes (the 32 high order bits from the second count and the TAI-UT offset) do not change very often. (besides that
tv_nsecis defined as a long, i.e. 64 bit on 64 bit machines and _signed_ , stupid if you ask me but I digress).
The filesystem writers can compact things as they see fit. I'm mostly talking about the stat(2) format.
-hpa
Quoted 7 lines · Andreas Dilger
Two notes I might make about this:
1) It would be good if it were possible to select this with a config option (I don't care which way the default goes), so that people who don't need/care about the increased resolution don't need the extra space in their inodes and minor extra overhead. To make this a lot easier to code, having something akin to theinode_update_time()which does all of the i_[acm]time updates as appropriate.
Am I missing something? That would make it two file types, no? I bet there's more overhead in handling that problem than just writing the time.
Quoted 8 lines
2) Updating
i_atimebased on comparing the nsec timestamp is going to be a killer. I think AKPM saw dramatic performance improvements when he changed the code to only do the update once/second, and even though you are "only" updating the atime if the times are different, in practise this will be always. Even without the "per superblock interval" you suggest we should probably only update the atime once a second (I don't think anything is keyed off such high resolution atimes, unlike make and mtime/ctime).
find -anewer seems to use as much resolution as it has. More to the point, what is the overhead of updating the time when an i/o is done? It would seem pretty trivial.
If you are willing to give up a flag bit you could store the time in some native unit (machine type dependent) when an i/o is done, then do the convert to ns when it's used, such as compare, close, etc. You could have an inode walker thread do the convert in background if that seems needed. There are probably other ways to reduce overhead, those just came to mind. I think it's a pretty low impact problem with some effort on making it so.
Quoted 7 lines
3) The fields you are usurping in struct stat are actually there for the Y2038 problem (when
time_twraps). At least that's what Ted said when we were looking into nsec times for ext2/3. Granted, we may all be using 64-bit systems by 2038... I've always thought 64 bits is much to large fortime_t, so we could always use 20 or 30 bits for sub-second times, and the remaining bits for extendingtime_tat the high end, and mask those off for now, but that is a separate issue...
As you say, but good that you brought it up!
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 10 lines · Bill Davidsen
Quoted 6 lines · Andreas Dilger
1) It would be good if it were possible to select this with a config option (I don't care which way the default goes), so that people who don't need/care about the increased resolution don't need the extra space in their inodes and minor extra overhead. To make this a lot easier to code, having something akin to the
inode_update_time()which does all of the i_[acm]time updates as appropriate.Am I missing something? That would make it two file types, no? I bet there's more overhead in handling that problem than just writing the time.
Not necessarily. Most filesystems don't even have space for storing a sub-second time resolution, so having the extra time resolution is irrelevant. For filesystems which do have room for sub-second timestamps they currently just fill in 0 there, and if the sub-second time is here they will fill in that field, so still no incompatible on-disk formats.
As for ext3 having sub-second timestamps, this will be done in a way which makes it compatible with older filesystem, so whether those timestamps are written or not written, the filesystem will still be readable on older kernels.
The "inode" space that I'm referring to is the in-memory inode struct, and the presence of that would be determined at compile time. Granted, it would only be 12 bytes added to the inode, but if you have thousands or millions of inodes resident you start to feel the pinch.
Quoted 9 lines
Quoted 8 lines
2) Updating
i_atimebased on comparing the nsec timestamp is going to be a killer. I think AKPM saw dramatic performance improvements when he changed the code to only do the update once/second, and even though you are "only" updating the atime if the times are different, in practise this will be always. Even without the "per superblock interval" you suggest we should probably only update the atime once a second (I don't think anything is keyed off such high resolution atimes, unlike make and mtime/ctime).
Quoted 3 lines
find -anewer seems to use as much resolution as it has. More to the point, what is the overhead of updating the time when an i/o is done? It would seem pretty trivial.
It would be trivial if you are already updating the inode (and we should optimize for this case), but if you are reading a file in 5-byte chunks and you update the atime a thousand times a second it most certainly IS a lot of overhead. We currently limit atime updates to 1/second by checking if the atime has changed or not. The proposed patch checks if the atime.ts_nsec has changed, and it most certainly will have, so this will always be updating the atime on disk.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
Quoted 9 lines · Andreas Dilger
Quoted 8 lines · Bill Davidsen
Quoted 6 lines · Andreas Dilger
1) It would be good if it were possible to select this with a config option (I don't care which way the default goes), so that people who don't need/care about the increased resolution don't need the extra space in their inodes and minor extra overhead. To make this a lot easier to code, having something akin to the
inode_update_time()which does all of the i_[acm]time updates as appropriate.
Quoted 8 lines
Quoted 2 lines
Am I missing something? That would make it two file types, no? I bet there's more overhead in handling that problem than just writing the time.
Not necessarily. Most filesystems don't even have space for storing a sub-second time resolution, so having the extra time resolution is irrelevant. For filesystems which do have room for sub-second timestamps they currently just fill in 0 there, and if the sub-second time is here they will fill in that field, so still no incompatible on-disk formats.
That was my concern.
Quoted 4 lines
As for ext3 having sub-second timestamps, this will be done in a way which makes it compatible with older filesystem, so whether those timestamps are written or not written, the filesystem will still be readable on older kernels.
I was more thinking of a kernel compiled without the hi-res timer code, if that should be done as an option.
Quoted 4 lines
The "inode" space that I'm referring to is the in-memory inode struct, and the presence of that would be determined at compile time. Granted, it would only be 12 bytes added to the inode, but if you have thousands or millions of inodes resident you start to feel the pinch.
I admit to being one of the "thousands" people, and even if I have 100k inodes (more likely to be 10% of that) it's in the order of a MB, and any machine which has 100k inodes open is likely to be large enough to ignore a MB. One advantage of keeping the HRT in the in-core inode is that it allows parallel make to work correctly even on a filesystem which doesn't have space to save that information.
Feel free to tell me if that last isn't true.
Quoted 13 lines
Quoted 9 lines
Quoted 8 lines
2) Updating
i_atimebased on comparing the nsec timestamp is going to be a killer. I think AKPM saw dramatic performance improvements when he changed the code to only do the update once/second, and even though you are "only" updating the atime if the times are different, in practise this will be always. Even without the "per superblock interval" you suggest we should probably only update the atime once a second (I don't think anything is keyed off such high resolution atimes, unlike make and mtime/ctime).Quoted 3 lines
find -anewer seems to use as much resolution as it has. More to the point, what is the overhead of updating the time when an i/o is done? It would seem pretty trivial.
Quoted 7 lines
It would be trivial if you are already updating the inode (and we should optimize for this case), but if you are reading a file in 5-byte chunks and you update the atime a thousand times a second it most certainly IS a lot of overhead. We currently limit atime updates to 1/second by checking if the atime has changed or not. The proposed patch checks if the atime.ts_nsec has changed, and it most certainly will have, so this will always be updating the atime on disk.
1 - any program which does unbuffered 5 byte reads is probably going to beat the machine to death anyway. Then the sysadmin will mount noatime.
2 - The patch isn't written in stone, going back to one per second shouldn't matter except in the case of network or devices shared between multiple systems (3.0?). processes on the same machine whould use the in-core information.
3 - updating once/sec could still be default, with HRT being a mount option like noatime.
4 - the time could be stored in register values, ticks, or whatever else, avoiding any conversion to ns. Then the time could be converted only when the inode was read, written out, etc.
I'd really like your comments on these, you probably see things I've missed.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 8 lines · Bill Davidsen
I admit to being one of the "thousands" people, and even if I have 100k inodes (more likely to be 10% of that) it's in the order of a MB, and any machine which has 100k inodes open is likely to be large enough to ignore a MB. One advantage of keeping the HRT in the in-core inode is that it allows parallel make to work correctly even on a filesystem which doesn't have space to save that information.
Feel free to tell me if that last isn't true.
It isn't true if the parallel make actually uses your RAM for something, thus flushing some of the inodes from RAM.
Admittedly it is no worse than we have at the moment. However, at the moment it is possible, to construct a "make" or other program of that ilk which can always make a safe decision: if it's ambiguous whether a file needs to be remade, then remake the file.
As soon as we have inodes time stamp resolution being spontanously lowered (because some of the inodes are flushed from RAM and some aren't), then it's not possible to make a safe program like that anymore, unless you simply ignore the high resolution time stamps _all_ the time, even when they are present.
You can just do that - it's correct behaviour. But it would be better to use the high precision when available, as that reduces the number of unnecessary remakes.
Quoted 6 lines
4 - the time could be stored in register values, ticks, or whatever else, avoiding any conversion to ns. Then the time could be converted only when the inode was read, written out, etc.
I'd really like your comments on these, you probably see things I've missed.
I know of exactly one application which depends on atime information:
checking whether you have new mail in your inbox. That's done by comparing atime and mtime on the mailbox. Mail readers read the file after writing it, MTAs will simply write it.
For this to function correctly, what's important is that the atime is updated to be at least the mtime. So for nanosecond atime updates, it makes sense that the _first_ read following a write should update the atime -- if not using the current clock, then simply copying the mtime value.
-- Jamie
Quoted 8 lines · Jamie Lokier
Quoted 7 lines · Bill Davidsen
I admit to being one of the "thousands" people, and even if I have 100k inodes (more likely to be 10% of that) it's in the order of a MB, and any machine which has 100k inodes open is likely to be large enough to ignore a MB. One advantage of keeping the HRT in the in-core inode is that it allows parallel make to work correctly even on a filesystem which doesn't have space to save that information.
Quoted 4 lines
Quoted 1 line
Feel free to tell me if that last isn't true.
It isn't true if the parallel make actually uses your RAM for something, thus flushing some of the inodes from RAM.
Hopefully it is being smart about doing that, or rather not doing that. But that would be a good thing to add to my responsiveness benchmark, to access a file, do a stat, and then do another stat later. Thanks for the idea, I expect to release a new version sometime this weekend.
Quoted 11 lines
Admittedly it is no worse than we have at the moment. However, at the moment it is possible, to construct a "make" or other program of that ilk which can always make a safe decision: if it's ambiguous whether a file needs to be remade, then remake the file.
As soon as we have inodes time stamp resolution being spontanously lowered (because some of the inodes are flushed from RAM and some aren't), then it's not possible to make a safe program like that anymore, unless you simply ignore the high resolution time stamps _all_ the time, even when they are present.
Quoted 3 lines
You can just do that - it's correct behaviour. But it would be better to use the high precision when available, as that reduces the number of unnecessary remakes.
I have to think about the point you raise of doing it one way or the other but not mixing. I had assumed that the inode of a file which was open would remain in core, and I want to look at the code before I form an opinion. If the file is not open or the inode is a non-file...
Quoted 12 lines
Quoted 6 lines
4 - the time could be stored in register values, ticks, or whatever else, avoiding any conversion to ns. Then the time could be converted only when the inode was read, written out, etc.
I'd really like your comments on these, you probably see things I've missed.
I know of exactly one application which depends on atime information:
checking whether you have new mail in your inbox. That's done by comparing atime and mtime on the mailbox. Mail readers read the file after writing it, MTAs will simply write it.
Quoted 5 lines
For this to function correctly, what's important is that the atime is updated to be at least the mtime. So for nanosecond atime updates, it makes sense that the _first_ read following a write should update the atime -- if not using the current clock, then simply copying the mtime value.
I think you may have missed the point of (4), some of the overhead of keeping HRT is the conversion of data to ns from some machine dependent information. Where possible the base information, such as a register, could be stored with a flag, avoiding the "convert to ns" CPU usage. The conversion could be done when the data was used, before save, at the time of a stat, etc. I have the feeling that would take some of the sting out of keeping HRT. It doesn't matter if it's atime, mtime or ctime, the atime was in response to "nobody uses HRT atime" in an earlier post.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 4 lines · Bill Davidsen
I have to think about the point you raise of doing it one way or the other but not mixing. I had assumed that the inode of a file which was open would remain in core, and I want to look at the code before I form an opinion. If the file is not open or the inode is a non-file...
Oh, the inode of a file which is open does remain in core. It's just that between runs of a program like "make", the file's aren't open are they?
Quoted 8 lines
I think you may have missed the point of (4), some of the overhead of keeping HRT is the conversion of data to ns from some machine dependent information. Where possible the base information, such as a register, could be stored with a flag, avoiding the "convert to ns" CPU usage. The conversion could be done when the data was used, before save, at the time of a stat, etc. I have the feeling that would take some of the sting out of keeping HRT. It doesn't matter if it's atime, mtime or ctime, the atime was in response to "nobody uses HRT atime" in an earlier post.
That's some of the overhead. The other overhead is reading the clock, which is quite high on x86 when TSC is not available. On a Pentium with no reliable TSC, I think that the time for a read() system call is comparable to the time to read the clock.
-- Jamie
Followup to: <[email protected]> By author: Jamie Lokier <[email protected]> In newsgroup: linux.dev.kernel
Quoted 6 lines
That's some of the overhead. The other overhead is reading the clock, which is quite high on x86 when TSC is not available. On a Pentium with no reliable TSC, I think that the time for a
read()system call is comparable to the time to read the clock.
Typically the way you deal with not having a usably cheap nanosecond-resolution clock is that you use the best available clock (say if HZ=1000 you'll increment by 1000000 each timer tick), and then simply use an atomic counter for the smaller divisions. This makes the relation "is A newer than B" correct, while avoiding the overhead of producing exact timestamps below the available resolution.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Quoted 9 lines · Jamie Lokier
Quoted 4 lines · Bill Davidsen
I have to think about the point you raise of doing it one way or the other but not mixing. I had assumed that the inode of a file which was open would remain in core, and I want to look at the code before I form an opinion. If the file is not open or the inode is a non-file...
Oh, the inode of a file which is open does remain in core. It's just that between runs of a program like "make", the file's aren't open are they?
I thought we were talking about parallel make, rather than "between runs." Your point is valid, but given the certainty that the inode has been recently used, hopefully the kernel is smart on releasing them.
My first thought is that the commonly used filesystems, other than ext2, do or will support high resolution time. NFS is its own nasty little problem.
Quoted 9 lines
Quoted 8 lines
I think you may have missed the point of (4), some of the overhead of keeping HRT is the conversion of data to ns from some machine dependent information. Where possible the base information, such as a register, could be stored with a flag, avoiding the "convert to ns" CPU usage. The conversion could be done when the data was used, before save, at the time of a stat, etc. I have the feeling that would take some of the sting out of keeping HRT. It doesn't matter if it's atime, mtime or ctime, the atime was in response to "nobody uses HRT atime" in an earlier post.
Quoted 4 lines
That's some of the overhead. The other overhead is reading the clock, which is quite high on x86 when TSC is not available. On a Pentium with no reliable TSC, I think that the time for a
read()system call is comparable to the time to read the clock.
Who uses a CPU without TSC? I guess the embedded folks and the people using really old systems. There was a suggestion on handling that posted, but I don't have it handy. Using the field as just a counter was the idea if I remember correctly. The NUMA folks have their own set of problems, I won't presume to even have an opinion on how they solve it, but if it needs doing I'm sure they can do it.
Thinking out loud:
To avoid overhead, the kernel needs to be smart about when the updated
inode info is written to storage Perhaps on writes when the data written actually falls off the elevator or transferred to a network peer. Until then the time can stay in memory, if the system goes down write data is lost, so having the inode reflect the time of the last completed write to storage isn't wildly wrong mtime.
For reads, having some bounded delay between the time of a system call
to read() and the time saved in the inode is of limited impact, as long as the time to update the inode to storage doesn't get wildly behind the time of the read. The one second you mentioned is probably aggressive if anything. That might have to be a tunable.
I haven't forgotten access via execute, I don't know if it differs from
read in practice.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 5 lines · Bill Davidsen
Quoted 3 lines
Oh, the inode of a file which is open does remain in core. It's just that between runs of a program like "make", the file's aren't open are they?
I thought we were talking about parallel make, rather than "between runs."
A parallel build often does call "make" separately many times, in parallel but not guaranteed to overlap all file opens. Between those, the files are closed.
Quoted 2 lines
Your point is valid, but given the certainty that the inode has been recently used, hopefully the kernel is smart on releasing them.
That's a "hopefully", and it depends on how much RAM you have as well as pure luck. I can live with that for building programs at home, but there are many applications where "hopefully" affecting correctness of behaviour is not acceptable.
Quoted 3 lines
My first thought is that the commonly used filesystems, other than ext2, do or will support high resolution time. NFS is its own nasty little problem.
Do they support nanosecond time, though, or do they round it to microseconds or something like that?
Quoted 1 line
[stuff about atime]
There seems to be general agreement that atime is not a very important value, with which I concur. (Why do we even bother with nanosecond atimes?)
I am only concerned about mtime, which is very useful indeed when we talk about building things which can detect changes to files.
Andi, I belive there is space in every architecture's stat64 (i.e. all those that have one) for a word describing the mtime resolution. If I code a patch to create that field, would you be interested?
-- Jamie
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 12 lines · Andreas Dilger
Quoted 10 lines · Andi Kleen
Move
time_tmembers in struct stat to struct timespec and allow subsecond timestamps for files. Too big to post on the list, because it edits a lot of file systems and drivers in a straight forward way.This is required for reliable "make" on fast computers.
File systems that support nsec storage are currently: XFS, JFS, NFSv3 (if the filesystem on the server supports it), VFAT (not quite nanosecond), CIFS (unit in 100ns which is above what linux supports), SMBFS (for newer servers)
Quoted 7 lines
Two notes I might make about this:
1) It would be good if it were possible to select this with a config option (I don't care which way the default goes), so that people who don't need/care about the increased resolution don't need the extra space in their inodes and minor extra overhead. To make this a lot easier to code, having something akin to theinode_update_time()which does all of the i_[acm]time updates as appropriate.
Please don't. Do not create incompatible versions of the same filesystem just because they were written on kernels compiled with different configurations. Superblock flags might be OK, but what is the point then? Better mount flags (mount with/without finegrained timestamps)?
[....]
Quoted 7 lines
3) The fields you are usurping in struct stat are actually there for the Y2038 problem (when
time_twraps). At least that's what Ted said when we were looking into nsec times for ext2/3. Granted, we may all be using 64-bit systems by 2038... I've always thought 64 bits is much to large fortime_t, so we could always use 20 or 30 bits for sub-second times, and the remaining bits for extendingtime_tat the high end, and mask those off for now, but that is a separate issue...
IMVHO, keeping fields in filesystems' inodes for 36 years in the future is daydreaming. Not even the filesystems in the just 11 year old Linux have survived unscathed... and by '38 we'll probably be by ext8 or so, under 64-bit CPUs.
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Quoted 8 lines · Horst von Brand
Quoted 6 lines · Andreas Dilger
1) It would be good if it were possible to select this with a config option (I don't care which way the default goes), so that people who don't need/care about the increased resolution don't need the extra space in their inodes and minor extra overhead. To make this a lot easier to code, having something akin to the
inode_update_time()which does all of the i_[acm]time updates as appropriate.
Quoted 4 lines
Please don't. Do not create incompatible versions of the same filesystem just because they were written on kernels compiled with different configurations. Superblock flags might be OK, but what is the point then? Better mount flags (mount with/without finegrained timestamps)?
I don't say anything about creating incompatible versions of the same filesystem. Configuring out nsec timestamps is no different than what we have today. Many filesystems do not support nsec timestamps anyways.
I just see this as one of many hundreds of "tiny" features that are added to Linux that could easily be made a config option when they are first added, but all just end up adding a tiny bit of bloat for people that don't need it.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
Re: Nightly regression runs against current bk tree
In reply to a message not in the archiveQuoted 20 lines · Mark Peloquin
Quoted 4 lines
Your correct. We're just getting started with this effort and we used this mix to get things going. Once ppl are happy with the presentation of data, we planned to add more tests to provide a more balanced mix. But since you asked, we have added lmbench to our -bk3 regression run. :)
Mark, it would be nice to get a graph of the combined results for each test. Something like:
tiobench sequential write rate
| +++++++++++++++++ + = -mm-ext3 M | ++++++++++++++++++++++++++***************** * = linus-ext3 B | +++++++***************** ###### # = -ac-ext3 / | . = -mm-XFS s | = = -ac-XFS | ********* etc |+----------------------------------------------------
date
Quoted 8 lines
This allows at-a-glance trends for each group of tests and (as in the example above you could see easily when a performance bug was added and fixed in -ac before in the linus kernel, for example). Probably having all of the comparable results on the same page, or even in the same graph results is a win.
Bonus points if you can click on a spot in the graph and get the results page for that date/test ;-).
This idea the STP team really, really likes. We'll start working on getting this type of report
into our framework.
Thanks much, Andreas - great explaination.
cliffw
Quoted 13 lines
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/