Date: Wed, 19 Aug 1998 04:25:27 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: peter.jeremy@auss2.alcatel.com.au (Peter Jeremy) Cc: hackers@FreeBSD.ORG Subject: Re: proposal to not change time_t Message-ID: <199808190425.VAA29417@usr06.primenet.com> In-Reply-To: <98Aug19.105412est.40322@border.alcanet.com.au> from "Peter Jeremy" at Aug 19, 98 10:54:27 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >How do you propose to deal with the fact that the file timestamp > >for FFS is a 32 bit value, and the spare fields that were intended > >to be used to resolve the 2039 bug have been stolen to store > >nanoseconds? > > One solution would be to add a creation time to the superblock (I > think struct fs has still got free space) and then just store offsets > from that creation time in the disk inodes (which are the critical > structure, size-wise). The times in struct stat would be the sum of > the fs_creat time and the relevant times in the disk inode. Har. And then I use backup/restore, and everything goes to hell. There is no choice but to put things back the way they were intended, IMO. Anything short of that (or a newfs, if that's refused) is really just taking another problem in lieu of the existing one. A sliding window, in other words, is not an option. > Whether > struct inode contains a 32-bit or 64-bit seconds counter would depend > on the relative efficiency/convenience of inode <-> dinode mapping > vs inode time updating (and stat()ing). If the unused parts of the > superblock are zero-filled, existing filesystems won't need updating > immediately to be compatible with the changed definition. Efficiency is not an issue, as of 2038, so long as there are tar files sufficient far in the past existant. > Storing the creation time as seconds only would mean that you don't need > to add/subtract the tv_nsec fields (which is particularly messy because > it wraps at an inconvenient 0x3b9aca00). The amount of relative time_t math based on the superblock values more than makes up for the storage requirements. Consider a full system restore onto a newly created FS. Existing archive formats don't have this relative offset stored. > This approach does mean that a filesystem won't last more than 69 > years, but that seems adequate. So did a two character date field, and a 2038 limit, when the issues were first originated. 8-). > A timestamp update tool would be > trivial to write, but will need exclusive access to a partition for > the time to read/write all the inodes (about the same as an fsck takes > now). For a somewhat higher cost (and with kernel assistance), it > should be possible to build a tool that can update the `fs_creat' and > all associated inode timestamps for an active filesystem. How can you tell the difference between an updated and a non-updated value if you carsh during update? Format conversion tools are always problematic, in that they need to synchronously log their progress. 8-(. > Alternatively, do we really need nsec timestamps in inodes? No, we don't. This was my point: this is a pure FreeBSD'ism, and has nothing to do with POSIX requirements (the fields are spare fields according to the POSIX spec, and reseerved for the upper 32 bits of a second counter in 2038, according the the design documents. Someone wanted nanosecond timing, and stole them from us... 8-(. > store a 64-bit seconds timestamp in the inode and have SYS_stat() map > it to a struct timespec with a zero tv_nsec. (Less convenient options > which address the make's difficulties in chronologically ordering > rapidly created files would be to use a 64-bit fixed-point number with > 8, 16 or even 24 fractional bits). This was my opinion on subsecond resoloution: thre are 8 bytes free to be used for that, if someone can show some utility. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808190425.VAA29417>