Linked by Thom Holwerda on Fri 23rd Oct 2009 21:13 UTC, submitted by poundsmack
Thread beginning with comment 391216
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
I've certainly seen this sort of thing happen - to some test systems thankfully. I just don't think ext4 is necessary in any way. ext3 was the end of the the line for the ext filesystem...
Hey! Extents are nice. And safe. 48 bit is nice. And safe. Delayed allocation was reckless... and not safe. Turn it off, and continue enjoying the stability of EXTx. And shame Ted T'so when appropriate. He'll notice, eventually. He's just living in his own little File-System Superstar world right now.
Edited 2009-10-26 23:01 UTC
Hey! Extents are nice. And safe. 48 bit is nice. And safe.
Yes they are nice additions, but I would have preferred the addressing of concerns like dynamic inode allocation which would have been a nice improvement over ext2/3. It's a very common problem, running out of inodes. I certainly understand the backwards compatibility reasons for that, but it's a very common and real problem nonetheless.
While I respect the need for backwards compatibility with filesystems and why new filesystems like ZFS often have a tough time, I can't help but feel we're at the end of the line.






Member since:
2005-07-06
I've certainly seen this sort of thing happen - to some test systems thankfully. I just don't think ext4 is necessary in any way. ext3 was the end of the the line for the ext filesystem line and I don't think stretching the codebase out any further to do things it wasn't mean to do has done anyone any good.