For anyone looking to learn a bit more about filesystems ext2 strikes a great balance of simplicity and real world practicality, making it good to learn from. Code here <a href="https://elixir.bootlin.com/linux/v3.9/source/fs/ext2" rel="nofollow">https://elixir.bootlin.com/linux/v3.9/source/fs/ext2</a>
I remember even into the early 2010s we would still just make for example /boot ext2 for simplicity sake (perhaps?). Is that still in practice? Haven’t been in the OS deployment weeds for a minute..
I'm not very familiar with Linux filesystem drivers, but it seems odd that there's separate ext2, presumably ext3, and ext4 drivers when the latter are (100%?) backwards-compatible with the former filesystems.
I really appreciate all this slow but inevitable work to solving the 2038 problem. In the wake of Y2K when we first talked about 2038 it was a joke, "ah we'll all be retired then and anyway computers will be totally different". But here we are now, 24 years later and 14 years before the actual deadline. Thankfully folks are doing the work of fixing the deeper system limitations.<p>I'm retired now but fully expecting to dust off a bunch of Unix skills in late 2037, early 2038. I suspect by then many people who know how to, say, build a Linux kernel from the command line will either be dead, retired, or too busy doing more fun things.
Related, list of filesystems and their rollover dates:<p><a href="https://github.com/y2038/y2038-list?tab=readme-ov-file#file-systems">https://github.com/y2038/y2038-list?tab=readme-ov-file#file-...</a><p>Note that the earliest date on the list is 2028 with isofs (used on CDs).
I don't understand the immediate concern about using 32 bits for file creation and modification times. Its reasonable to assume that if the value has overflown and is very low that its not indicating a date from 1970. There is probably room to add a single bit indicating if the epoch is 1970 or 2038.