At 7:46 AM -0600 6/6/05, Scott Long wrote: >Garance A Drosihn wrote: >>At 1:05 AM -0400 6/6/05, Suleiman Souhlal wrote: >>> >>>Talking about going to 64-bit inode numbers, how would we deal >>>with the change in stat(2)? >> >> >>By making some sort of incompatible change to stat(2). This has >>been discussed from time-to-time. It's another change that I >>would have liked to have seen (at least for the stat routines) >>in 6.0, but right now I suspect it will not happen until 7.0. > >We can't go making incremental incompatibilities to the filesystem >without a good deal of planning. This is the type of thing that >would go into a 'UFS3'. I am not talking about a new file system (not for 6.0, certainly!). I am just talking about a new layout for 'struct stat'. Yes, it is an incompatible change, but it would not be changing any filesystems. In fact, all I wanted for 6.0 was a new 'struct stat' where all the fields are the same size as they are right now, but many of them have extra space reserved so that some later commits could change from 32-bit values to 64-bit values. I realize that even what I wanted to do is too much of a jump at this point for 6.0-release. I'm simply saying that if we drop back to a year ago, at that time I was hoping a new 'struct stat' would be ready for 6.0. This was explicitly discussed at the dev-summit at the 2004 Usenix in Boston, for instance. -- Garance Alistair Drosehn = gad_at_gilead.netel.rpi.edu Senior Systems Programmer or gad_at_freebsd.org Rensselaer Polytechnic Institute or drosih_at_rpi.eduReceived on Mon Jun 06 2005 - 15:51:57 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:35 UTC