Re: the " 'official' point of view" expressed by kernelnewbies.orgregarding reiser4 inclusion

[David Masover]

Jan-Benedict Glaw wrote:
> On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich <reiser4@xxxxxxxxxxxxxxxx> wrote:
> > A colleague of mine happened to create a ~300gb filesystem and started
> > to migrate Mailboxes (Maildir-style format = many small files (1-3kb))
> > to the new LUN. At about 70% the filesystem ran out of inodes; Not a
>
> So preparation work wasn't done.

So what?

Yes, you need to do preparation.  But it is really nice if the 
filesystem can do that work for you.

Let me put it this way -- You're back in college, and it's time to write 
a thesis.  You have a choice of software packages:



Package A:  You have to specify how many pages, and how many words, 
you're likely to use before you start typing.  Guess too high, and 
you'll print out a bunch of blank pages at the end.  Guess too low, and 
you'll run out of space and have to start over, copy and paste your 
document back in, and hope it gets all the formatting right, which it 
probably won't.

Package B:  Your document grows as you type.  When it's time to print, 
only the pages you've actually written something on -- but all of the 
pages you've actually written something on -- are printed.



All other things being equal, which would you choose?  Which one seems 
more modern?

Look, I understand the argument against ReiserFS v3 -- it has another 
limitation that you don't even know about.  That other limitation is 
scary -- that's like being able to type as many words as you want, but 
once you type enough pages (no way of knowing how many), pages start 
randomly disappearing from the middle of your document.

But the argument that no one cares about inode limits?  Really, stop 
kidding yourselves.  It's 2006.  The limits are starting to look 
ridiculous.  Just because they're workable doesn't mean we should have 
to live with them.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/