Re: Corrupted/unreadable journal: reiser vs. ext3

Re: Corrupted/unreadable journal: reiser vs. ext3

[Dirk Schenkewitz]

Sorry for being that late, I didn't see it on first view.

Sam Vilain wrote:

> On Wed, 12 Feb 2003 08:43, berthiaume_wayne@emc.com wrote:
> > Dirk, I'd be interested in hearing from you your performance
> > experience with ext3 when it reaches 96% full.
> 
> No problem, because you get ENOSPC at 95% or 90%.

Not at my system - I have (for example) a 16 Gig partition with
ext3 on it which is 100% full and has now 6100 kilobytes free space.
No Problem (with getting ENOSPC, I mean :-)).
Oh - wait a sec: do you usually reserve 5%-10% for the superuser?
That might explain why you get ENOSPC at 95%-90%, because that
reserved space is not taken into account... I normally tune the
fs to reserve 0% for the superuser. I never needed the reserved
space anyway.

> Hmm, another feature SysAdmins actually find useful, missing in 
> reiserfs.
> Along with quotas (this feature is a lazy case of a quota, really).
> 
> On Wed, 12 Feb 2003 18:12, Ross Vandegrift wrote:
> > You have to start your software on some kind of foundation.
> > Working hardware sounds like a great place to me.
> 
> Hmm, you've never heard of redundancy or fault tolerance then.
> 
> What part fails the most in running systems ?  Disk platters.
> 
> CPUs might overheat and RAM might suddenly one day get a sticky bit,

Even then I'd like the OS to find out about that and inform me...

> but as  you point out there ain't much you can do about it.
> Except buy a Tandem, or use ECC memory.
>
> But with disks, you can.  Mirroring aside, modern hard disks use S.M.A.R.T. 
> technology which claims to be able to spot failures before they happen.  
> Many BIOSes will let you turn this feature on and off.  Of course I've 
> never actually seen it in action :-).

For me the most important thing is: if something is vital to a fs,
it must be protected even against hardware failure as good as possible.
For example, by making copies, or (perhaps) at least having reserved
space for a copy, and if some access fails, mark the blocks as bad,
give a warning (important) and start using the reserved space. 

Have fun
	dirk
-- 
Dirk Schenkewitz 

InterFace AG                 fon: +49 (0)89 / 610 49 - 126
Leipziger Str. 16            fax: +49 (0)89 / 610 49 - 83
D-82008 Unterhaching         
http://www.interface-ag.de   mailto:dirk.schenkewitz@interface-ag.de

Re: Corrupted/unreadable journal: reiser vs. ext3

[Juan Quintela]

>>>>> "dirk" == Dirk Schenkewitz <Dirk.Schenkewitz@interface-ag.com> writes:

Hi

dirk> Not at my system - I have (for example) a 16 Gig partition with
dirk> ext3 on it which is 100% full and has now 6100 kilobytes free space.
dirk> No Problem (with getting ENOSPC, I mean :-)).
dirk> Oh - wait a sec: do you usually reserve 5%-10% for the superuser?
dirk> That might explain why you get ENOSPC at 95%-90%, because that
dirk> reserved space is not taken into account... I normally tune the
dirk> fs to reserve 0% for the superuser. I never needed the reserved
dirk> space anyway.

that 5-10% is there not for the superuser (with today disks, that is
a lot of space).  I was also going to reduce the percentage, but then
somebody explained me that this porcentange needs to be free at all
times to maintain the fragmentation low.  And that makes a lot of
sense, the bigger the disk, the more free space you need to have low
fragmentation.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: Corrupted/unreadable journal: reiser vs. ext3

[Anders Widman]

> that 5-10% is there not for the superuser (with today disks, that is
> a lot of space).  I was also going to reduce the percentage, but then
> somebody explained me that this porcentange needs to be free at all
> times to maintain the fragmentation low.  And that makes a lot of
> sense, the bigger the disk, the more free space you need to have low
> fragmentation.

That   is   "free"  space  that  needs  to  be  free  to  lessen  the
fragmentation.  All  the users won't see this free space - and you end
up with high fragmentation anyway?

cheap quota systems (was: Re: Corrupted/unreadable journal: reiser vs. ext3)

[Zygo Blaxell]

In article <86isvfg2rr.fsf@trasno.mitica>,
Juan Quintela  <quintela@mandrakesoft.com> wrote:
>that 5-10% is there not for the superuser (with today disks, that is
>a lot of space).  I was also going to reduce the percentage, but then
>somebody explained me that this porcentange needs to be free at all
>times to maintain the fragmentation low.  And that makes a lot of
>sense, the bigger the disk, the more free space you need to have low
>fragmentation.

The purpose may originally have been to reduce fragmentation, but it
is certainly _useful_ as a kind of cheap quota system.  And if you
look closely at the ext[23] superblock, you'll notice that the extra
amount can be allocated to specific users, or even groups, instead
of root.

This is by far the one feature of ext[23] that I miss most on reiserfs.
Usually I don't need quotas or separate partitions, but I do need the
system to be able to write system logs or queue mail for a few hours
after a non-privileged user fills up the entire disk, and that's usually
the only reason why I'd normally want to restrict any user's ability to
use all available disk space.

It's possible to achieve this effect using quotas or partitions, but
the administrative overhead is excessive--in the normal case I'd have
to adjust normal Unix-style disk quotas of all users in real time,
or repartition read-write mounted filesystems on the fly.  Filling in
the appropriate values in an ext2 superblock is quick, easy, fast,
and often sufficient.

The feature I'd _really_ like to see is a kind of "negative" quota.
Instead of an upper bound on the total amount of space a user uses, I'd
prefer to specify a lower bound on the amount of free space left on the
disk before allowing a user to allocate more.  This would allow classes of
users to share limited disk space at different thresholds of "fullness",
where allocation of the total space within a class is limited but
allocation of space by particular users in a given class is not
restricted.  Note that by "user" I usually mean "server process uid" here.

-- 
Zygo Blaxell (Laptop) <zblaxell@feedme.hungrycats.org>
GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD