Matthias Buelow writes:
> Greg Oster writes:
> 
> >>   | bytes/sector: 512
> >>   | sectors/track: 256
> >>   | tracks/cylinder: 1
> >>   | sectors/cylinder: 256
> >>   | cylinders: 139970
> >> 
> >> Yes, that's certainly not a good layout.   If you don't have the kernel
> >> patch mentioned on the list, then allocating new blocks is (sometimes)
> >> likely to be very slow (CPU intensive).
> >
> >This is the problem that Herb mentioned...
> 
> Hmm.. what layout would be recommended?  How can I calculate
> a more optimal layout?

Basically pick a tracks/cylinder value larger than 1 (8 or larger is probably 
fine.)  Even 32/8/133970 is probably better than the current 256/1/133970.
64/32/16746 might be even more reasonable.

> >A couple of other things:
> >
> >Matthias Buelow writes (in a previous message):
> >> START layout
> >> # sectPerSU SUsPerParityUnit SUsPerReconUnit RAID_level
> >> 32 1 1 5
> >
> >That's only 16K per component in this case, which is probably too small 
> >for the best performance... 32K per component may perform better.
> 
> I thought, since there're mostly smaller files on the disk, that
> smaller components would be better, since it wouldn't have to read
> in that much then just for a single file (but I must admit, that was
> only an unbased speculation, I am rather clueless about these details
> of RAIDs in general, so I took the sample values from the manpage...)
> 
> >Also: do a 'time ls -l > /dev/null' on the offending directory, and a 
> >'time ls -l > /dev/null' on the "single disk of the same type".  I'm 
> >interested in seeing what those say... 
> 
> here's a non-stat()ing ls which just reads the dir:
> 
> $ time \ls -1|wc -l
>      934
>     0.01s real     0.00s user     0.01s system

Can you try the same thing under csh?  What I really want to see is the 
IO values and page-fault values.

Also: the entries in this directory are all files, yes?

> and here comes the problematic thing:
> 
> $ time \ls -l >/dev/null
>    33.26s real    12.15s user    16.69s system
> $ time \ls -l >/dev/null
>    31.01s real    12.95s user    16.08s system
> $ time \ls -l >/dev/null
>    32.78s real    13.17s user    15.61s system
> 
> I don't have access to a non-RAID DNES atm (I was referring to
> a disk at home, in a similar setup, except for the RAID) but
> here are the times for /dev which is of similar size, on the
> same system, on a RAID1 (using two DDRS disks, which are much
> slower than the DNES used for the RAID5 though):
> 
> $ time \ls -1 /dev|wc -l
>      875
>     0.03s real 42949672.95s user     0.01s system

Woah! What a value!  497 days just do do an ls! :)

> $ time \ls -l /dev>/dev/null
>     0.05s real     0.01s user     0.00s system
> $ time \ls -l /dev>/dev/null
>     0.05s real     0.02s user     0.02s system
> $ time \ls -l /dev>/dev/null
>     0.04s real     0.01s user     0.00s system
> 
> The fact that the directory on the RAID5 contains only subdirs
> as entries, and in /dev it's device nodes shouldn't be of any
> significance, imho?

Device nodes shouldn't matter. 
 
> >i386 box running 1.5.1_BETA as of Apr. 7)
> 
> The machine is running 1.5/i386.
> 
> --mkb

Later...

Greg Oster