Re: [RFC 0/13] extents and 48bit ext3
Jeff Garzik <[email protected]>
| Newsgroups | gmane.linux.file-systems,gmane.linux.kernel,gmane.comp.file-systems.ext2.devel |
|---|---|
| Message-ID | <[email protected]> |
Andrew Morton wrote: > On Fri, 09 Jun 2006 11:40:03 -0400 > Jeff Garzik <[email protected]> wrote: > >> Users are now forced to remember that, if they write to their filesystem >> after using either $mmver or $korgver kernels, they are locked out of >> using older kernels. > > The same happens if we create ext4 - earlier kernels don't support that, > either. > > I suppose we could call it ext4, although that wouldn't make much > difference operationally. The developers would probably choose to generate > ext4 from the same codebase as ext3 for maintainability reasons, rather > than choosing to copy-n-modify. We'd need to see the patches to be able to > finally make that judgement. I would propose the obvious... 'cp -a ext3 ext4', apply the extent and 48bit patches, and then do the obvious search-n-replace. I guarantee that developer momentum would take over from there. Rather than fundamentally change ext3, let's let it stabilize. >> And as features continue to be added in this manner, this problem gets >> _exponentially_ worse. > > "continue to be added"? afaik this is the first time this has happened, > and there's no plan to do it again. ext3 developers are _fundamentally changing_ the block allocation structure [in a good way]. If they can get away with it once, they will continue to modify ext3, adding btrees and other new gadgets. That's just human nature. For example, htree was a minor disaster, deployment-wise, on the distro vendor side. I think extents and 48bit are so fundamental that it's silly to attempt to minimize the impact from the user's perspective, and moreover, I think Linux benefits more if ext3 is _not_ kept on life support this way. We need to draw a line in the sand. If we don't, no one ever will. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html