linux-kernel - Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 24 Jul 2006 13:37:13 -0700
From:	Mike Benoit <ipso@...ppymail.ca>
To:	"Horst H. von Brand" <vonbrand@....utfsm.cl>
Cc:	Matthias Andree <matthias.andree@....de>,
	Hans Reiser <reiser@...esys.com>, lkml@...productions.com,
	Jeff Garzik <jeff@...zik.org>, Theodore Tso <tytso@....edu>,
	LKML <linux-kernel@...r.kernel.org>,
	ReiserFS List <reiserfs-list@...esys.com>
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org
	regarding reiser4 inclusion

On Mon, 2006-07-24 at 14:06 -0400, Horst H. von Brand wrote:
> > And EXT3 imposes practical limits that ReiserFS doesn't as well. The big
> > one being a fixed number of inodes that can't be adjusted on the fly,
> 
> Right. Plan ahead.

That is great in theory. But back to reality, when your working for a
company that is growing by leaps and bounds that isn't always possible.
Why would I want to intentionally limit myself to a set number of inodes
when I can get a performance increase and not have to worry about it by
simply using ReiserFS? 

It all boils down to using the right tool for the job, ReiserFS was the
right tool for this job. 

> > I've been bitten by running out of inodes on several occasions,
> 
> Me too. It was rather painful each time, but fixable (and in hindsight,
> dumb user (setup) error).
> 
> >                                                                 and by
> > switching to ReiserFS it saved one company I worked for over $250,000
> > because they didn't need to buy a totally new piece of software.
> 
> How can a filesystem (which by basic requirements and design is almost
> transparent to applications) make such a difference?!

Very easily, the backup software the company had spent ~$75,000 on
before I started working there used tiny little files as its "database".
Once the inodes ran out the entire system pretty much came to a
screeching halt. We basically had two options, use ReiserFS, or find
another piece of software that didn't use tiny little files as its
database. If I recall correctly the database went from about 2million
files to over 40 million in the span of just a few months. No one could
have predicted that. I believe this database was on an 18GB SCSI drive,
so even using 1K blocks wouldn't have worked. According to the mke2fs
man page:

"-i bytes-per-inode
This value generally shouldn't be smaller than the blocksize  of
the filesystem,  since  then  too many inodes will be made."

The only other option at that time was to purchase Veritas backup and
its not cheap. We ended up switching to ReiserFS, it increased our
backup/restore time immensely and also bought us about 1year before the
system finally outgrew itself for good. By that time the company could
afford to drop $250,000 on high end backup software so we could grow
past 10TB.

-- 
Mike Benoit <ipso@...ppymail.ca>

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)