Best of CUSM: Comparisons of file systems

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

Xref: world comp.unix.sco.misc:102516
Newsgroups: comp.unix.sco.misc
Path: world!blanket.mitre.org!newsfeed.berkeley.edu!news.he.net!news.louisville.edu!uky.edu!xenitec!news
From: "Radek Tomis" <rts@mediumsoft.cz>
Subject: Re: Why v5.0.x emergency floppies take so long to load ? (solved)
Resent-From: mmdf@xenitec.on.ca
Submit-To: scomsc@xenitec.on.ca
Content-Type: text/plain;
        charset="iso-8859-2"
Organization: Medium Soft, a.s.
Date: Fri, 6 Aug 1999 16:36:11 GMT
Message-ID: <04a801bee029$e29f3c40$8e0314ac@rtsnt> 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
References: <019f01becf62$30f21a30$8e0314ac@rtsnt> <006a01bed1c1$35509780$8e0314ac@rtsnt> <FF4Kr1.20rr@wjv.com.REMOVEME> <001301bed40c$e3f828a0$8e0314ac@rtsnt> <FFA00s.oJ5@wjv.com.REMOVEME> 
Sender: news@xenitec.on.ca (xenitec.on.ca News Administrator)
Precedence: list
Lines: 438
X-Mozilla-Status: 8011

> From: Bill Vermillion <bill@wjv.com.removeme>
> Sent: Thursday, July 22, 1999 4:24 PM

> In article <001301bed40c$e3f828a0$8e0314ac@rtsnt>,
> Radek Tomis <rts@mediumsoft.cz> wrote:
> >> From: Bill Vermillion <bill@wjv.com.removeme>
> >> Sent: Monday, July 19, 1999 6:06 PM
>
> >> In article <006a01bed1c1$35509780$8e0314ac@rtsnt>,
> >> Radek Tomis <rts@mediumsoft.cz> wrote:
> >
> >[...]
>
> (first part of discussion on slow loads deleted - wjv)

> >It's not a problem of v5.0.x "/boot" only. It's a problem of
> >all versions of "/boot". It doesn't read from EAFS file systems
> >(used by `mkdev fd` for v5.0.x emergency floppies) as quickly as
> >possible. More details below.
>
> That's interesting.  I have found in testing the the old Xenix
> file system is about the slowest around.  However for a floppy
> system that shouldn't be a problem.  I wonder what the thinking
> is on an EAFS boot disk.  Curious?

Good point.
EAFS (and also AFS, S51K, ES51K and even HTFS) layout is basically the same
as XENIX as far as reading is concerned, so you made me do more tests and I
found that unlike I said in my previous post, EAFS performs as good/bad as
XENIX.

I had either done something wrong in previous tests or happened to test
XENIX FS only with certain settings and on certain (faster) machine,
resulting in half time load for XENIX vs. EAFS (see notice for "*" under the
table below). And last but not least, AirBag (its "readme" and mostly XENIX
vs. EAFS comment in "/etc/airbag") led me astray little bit, because I had
thought (and one test that I cannot reproduce anymore confirmed this) that
the difference between EAFS and XENIX is in the file system type itself. Not
so, the difference is only in settings used to create XENIX and EAFS.

The following table shows more (results were double verified):

tls620, boot floppy disk only (v5.0.5 kernel, size 2.01 MB, compressed size
947 KB):

+---------------------------------------------------------+
| FS, gap/bpc, interleave      time to load "/unix.Z"     |
+---------------------------------------------------------+
|                          P-100, 32MB   P-200 MMX, 32 MB |
| EAFS,   1/400,  1:1,     3'09"         3'10"            |
| EAFS,   1/ 18,  1:1,     3'09"         3'09" *          |
| EAFS,   1/  9,  1:1,     3'09"         3'09" *          |
| EAFS,   2/ 18,  1:1,     3'09"         3'10"            |
| EAFS,   2/  9,  1:1,     3'09"         3'10"            |
| EAFS,  #2/ 18,  1:1,       50"                          |
|                                                         |
| EAFS,   1/400,  1:2,     1'02"         1'00"            |
| EAFS,   1/ 18,  1:2,     1'00"         1'00"            |
| EAFS,   1/  9,  1:2,     1'00"         1'01"            |
| EAFS,   2/ 18,  1:2,     1'07"         1'08"            |
| EAFS,   2/  9,  1:2,     1'07"         1'07"            |
| EAFS,  #2/ 18,  1:2      1'33"                          |
|                                                         |
| XENIX,  1/400,  1:1,     3'09"         3'10"            |
| XENIX,  1/ 18,  1:1,     3'09"         3'10"            |
| XENIX,  1/  9,  1:1,     3'09"         3'09" *          |
| XENIX,  2/ 18,  1:1,     1'00"         1'00"            |
| XENIX,  2/  9,  1:1,       49"           49"            |
|                                                         |
| XENIX,  1/400,  1:2,     1'00"         1'01"            |
| XENIX,  1/ 18,  1:2,     1'00"         1'01"            |
| XENIX,  1/  9,  1:2,     1'01"         1'01"            |
| XENIX,  2/ 18,  1:2,     1'42"         1'42"            |
| XENIX,  2/  9,  1:2,     1'32"         1'32"            |
+---------------------------------------------------------+

gap - rotational file system gap (FS interleave) in FS
      blocks (XENIX) or clusters (EAFS)
    - XENIX 1K: 1 = no gap (1:1), 2 =  1K gap (1:2), 3 =  2K gap (1:3),
      and so on
    - EAFS 1K, cluster 16K: 1 = no gap (1:1), 2 = 16K gap (1:2)
    - EAFS 1K, cluster 1K:  1 = no gap (1:1), 2 =  1K gap (1:2)

bpc - number of file system Blocks Per Cylinder
    - effective with XENIX FS and gap != 1 only

interleave - physical sector interleave ('format <device> -i interleave')

* - For these tests (and another XENIX test also on P-200 MMX that
    I can't remember, because I threw the paper to the bin just
    after my previous post, thinking "I'm done"), I believe
    (I had them written down) I really got the half time
    (1'28" vs. 3'09"), but I haven't been able to reproduce
    them, although tried several times (always got 3'09" or
    3'10"). That's still a little mistery for me.

# - EAFS created with 1K clusters (`mkfs -f EAFS <device> 2880 2 <bpc>
    -E -C 1`) to get effective gap of 1K only as opposed to 16K for
    all other EAFS tests used with default cluster size 16K. P-200
    MMX tests are missing, because I was not going to try this
    different cluster size setting until few moments ago. I've gotten
    this idea during update of this article.


"/unix.Z" disk blocks layout:

 - EAFS,1/400 == EAFS,1/18 == EAFS,1/9 (no gap)

 - EAFS,2/18 == EAFS,2/9 (16K gap)

 - EAFS,2/18 with cluster size 1K (1K gap):
   blocks: large contiguous chunks with 1K gaps, example only:

   162    164     166     ...     690     692
       183     185     187    ...    1204    1206
       699     701     703    ...    1436    1438
   [...]

   - track layout:
      cyl 0, head 0: 5K
      cyl 0, head 1: 4K
      cyl 1, head 0: 5K
      cyl 1, head 1: 4K
      ---
      cyl 2, head 0: 5K
      ...
   - almost constant 1K rotational gap

 - XENIX,1/400 == XENIX,1/18 == XENIX,1/9 (no gap)

 - XENIX,2/18:
   blocks, (0 = cylinder boundary):

     0     2     4     6     8    10    12    14    16
        1     3     5     7     9    11    13    15    17
    18    20    22    24    26    28    30    32    34
       19    21    23    25    27    29    31    33    35
    ..
       ..

   - track layout:
      cyl 0, head 0: 5K
      cyl 0, head 1: 4K
      cyl 0, head 0: 4K
      cyl 0, head 1: 5K
      ---
      cyl 1, head 0: 5K
      ...
   - constant 1K rotational gap with exception of 2K and 0K gap once
     for each cylinder (!)

 - XENIX,2/9:
   blocks, (0 = cylinder boundary):

        1     3     5     7
     0     2     4     6     8
       10    12    14    16
     9    11    13    15    17
       19    21    23    25
    18    20    22    24    26
       ..
    ..

   - track layout: 4K, 5K, 4K, 5K, ...
      cyl 0, head 0: 4K
      cyl 0, head 0: 5K
      cyl 0, head 1: 4K
      cyl 0, head 1: 5K
      ---
      cyl 1, head 0: 4K
      ...
   - constant 1K rotational gap




The problem of slow load with compressed v5.0.x emergency set is perhaps in
16-bit implementation of decompressing algorithm ('file /boot' => "... 86
executable"), because my load simulation with standard 32-bit i386
'compress' binary worked fine:

+----------------------------------------------------------+
|    time compress -d < /mnt/unix.Z > /tmp/ramdisk/unix    |
|  time fsrd -s /dev/rfd0 inode -d 8/9 | compress -d > ... |
|                                                          |
| FS, gap/bpc, interleave                      time        |
+----------------------------------------------------------+
|                                        P-100, 32 MB RAM  |
| EAFS,   1/400,  1:1,                          34"        |
| EAFS,   1/ 18,  1:1,                          34"        |
| EAFS,   2/ 18,  1:1,                          43"        |
| EAFS,   1/400,  1:2,                          54"        |
| XENIX,  1/400,  1:1,                          34"        |
| XENIX,  1/  9,  1:1,                          34"        |
| XENIX,  2/  9,  1:1,                          43"        |
| XENIX,  1/  9,  1:2,                          54"        |
+----------------------------------------------------------+

Reading from raw floppy device (using my own tool `fsrd`) ensured that no
system cache/buffer was in use to read from floppy.


BTW, during the tests I managed to combine both v4.2 emergency floppies
(BOOT+ROOT) on single one (1.44M) (/boot + compressed kernel copied onto
ROOT floppy plus removing some unnecessary stuff) and I shortened the time
to load emergency set even further:

v4.2 emergency boot floppy disk only (v4.2 kernel, size 919 KB, compressed
size 408 KB):

+----------------------------------------------------------+
| FS, gap/bps, interleave             time to load "/unix" |
+----------------------------------------------------------+
| EAFS,   1/400,  1:1,                        41"          |
| EAFS,   1/ 18,  1:1,                        41"          |
| XENIX,  1/ 18,  1:1,                        41"          |
+----------------------------------------------------------+

+----------------------------------------------------------+
| FS, gap/bpc, interleave           time to load "/unix.Z" |
+----------------------------------------------------------+
| EAFS,   1/400,  1:1,                      1'35"          |
| XENIX,  1/ 18,  1:1,                      1'35"          |
| XENIX,  1/  9,  1:1,                      1'35"          |
| XENIX,  2/ 18,  1:1,                        31"          |
| XENIX,  2/  9,  1:1,                        26"          |
| XENIX,  1/ 18,  1:2,                        32"          |
| XENIX,  1/  9,  1:2,                        32"          |
| XENIX,  2/ 18,  1:2,                        50"          |
| XENIX,  2/  9,  1:2,                        45"          |
+----------------------------------------------------------+



[RecoverEDGE's emergency set loads as slow as standard v5.0.x set]
>
> It's interesting to note your comment about BackupEdge recover
> disks.  I've never had them take much more than a minute or two
> to load..

Right, because of different interleave (see EAFS 1/400, 1:1 vs. 1:2 in the
first table above).

> >In addition, AirBag uses 1K rotational gap (high-level interleave)
> >for XENIX FS. I suppose this I/O slowdown is needed in order for
> >slow decompressing (used in "/boot") of v5.0.x compressed kernel
> >and root file system image could keep up with I/O flow and prevent
> >extra revolutions. Wonder what it would be like with physical 1:2
> >interleave and no user-level gap.
>
> I'd suspect they would be the same.

Yes, for 18 blocks per cylinder it is the same.
(XENIX, 2/18, 1:1  vs.  XENIX, 1/18, 1:2)

Some thoughts on this (that most probably don't impact emergency set load
time at all):
While 2/18 needs twice as much head switches as 1/<any> (see block layout
above), there is twice as much idle time for decompressing with 2/18 (1K
logical gap vs. 1 sector (0.5K) physical gap), thus some extra rev might be
sometimes required for 1:2. Assuming '/boot' reading from floppy via BIOS in
1K (2 sectors) chunks and decompressing synchronously. The 1 sector spin
idle time with 1:2 interleave is wasted while waiting (inside BIOS code) for
the 2nd sector to appear under the head.


For 9 blocks per cylinder it is slower (20%).
(XENIX, 2/9, 1:1  vs.  XENIX, 1/9, 1:2)

> >Changing rotational gap from 1 (no gap) (used by default for both
> >SCO v4.2 and v5.0.x mergency set) to 2 (1K gap) makes the v5.0.x
> >emergency set's load roughly twice as fast. This gap change is
> >contra-productive for v4.2 set, because decompression isn't used,
> >and the gap slows the loading a bit (20%).
>
> I wonder if someone assumed that in this world of high-performance
> HD's and buffers on the HD themselves, that someone just set
> this up for a 1:1 interleave.  It should be okay on some systems,
> but will be a pig on others.
>
> I learned a lot about this a long time ago (20 really) when I was
> using an OS that let you 'tune' how it was to run.  Floppy drives
> had a lot of different track-track access times.  Format a disk on
> a drive with fast track to track access and read it on a slow one
> seem to take forever. We'd blow 10 rev - at least - on a read.
>
> Take a drive that spins at 300RPM. Thats 5 revolutions per second.
> If it would read a 1:2 interleave that takes 2/5ths of a second
> to read the track after taking into account access time and head
> settling.  Total probably 1/2 second factoring in (as a guess) the
> latency, settling time, etc.

> Blowing 10 revs means 10/5ths of a second - or two seconds for
> each track.  Depending on a variety of factors the 1:1 is going to
> be 1/4th the speed.  That matches your 8 minutes vs 2 minutes,
> does it not?

Right, 10 vs. 2 revs roughly corresponds to 8 vs. 2 minutes.
But from what did you derive those 10 revs ?
>From experience with different floppy drives mentioned above ?
I'm a bit confused here.


The difference between XENIX 2/18,1:1 vs. 2/9,1:1 (1'00" vs. 49"):

> >I've found yet another trick how to short cut the time to load
> >v5.0.x set. Changing number of blocks per cylinder (when creating
> >XENIX FS) from 18 (9K) to 9 (4.5K) makes the load about 20% faster.
> >I find this strange (3,1/2" DSHD floppy has 9K optimal block size
> >(track size)), but that's what I've found.
>
> I can sort of envision this (just musings on my part here) in
> relation ship to interleave.  4.5K block size is the block
> for 1 revolution - 1/2 the sectors.   So each revolution gets
> one block of smaller size instead of two revolutions for the larger
> size. Just a guess however.

Well, I could agree, but only if it would be in relationship to *physical*
(1:2) interleave, which I actually tested (reading 1:2 floppy raw device
with 4.5K vs 9K block size) and there's really no difference.

However, since here we have logical FS interleave (gap parameter), the
"/boot" (or any other SW for that matter) cannot use different block size
other than 2 or 1 sector (1 or 1/2 KB), because file's blocks (and sectors)
are not contiguous (with gap=2), so you can't read (in almost all cases)
more than one block at once (i.e. AFAIK you can't tell floppy drive to read
sectors 1,2,5,6,9,10,13,14,17,18, all in one operation). Of course, with
physical interleave, this is transparent to SW, and whole track (9K) or half
of the track (4.5K) can be requested at once, provided that file's block in
the filesystem are contiguous.

My theory, now that I understand the FS layout in regard of gap and bpc, is
different.

First of all, I found out that the gap parameter does not mean number of
physical blocks (512-byte sectors) per cylinder as EAFS version of mkfs
displays. It means number of logical file system blocks (as I guessed in the
previous post), so gap 18 means 18 KB cylinder size (using 1KB logical
blocks).

Now if you take a look at the XENIX 2/18 (1:1) block layout (under the first
table above), you will notice, that once per each cylinder, there are two
consecutive blocks without any gap. The XENIX 2/9 and also EAFS 2/<any> with
1K clusters layouts don't have any rotational gap missing.

As you said, one rev is worth of 0.2 seconds. For "/unix.Z" (947 KB) on
XENIX 2/18, there are 52 (947K / 18K) rotational gaps missing (0K gaps). 52
extra revs are worth of 10.4 seconds, which matches 1'00" vs. 49" or 50"
difference.

> >So here is the procedure to turn way too slow v5.0.x emergency set
> >into fast one:
>
> Good info.

This procedure (XENIX, 2/9) still remains the best combination (as well as
new one discovered a while ago: EAFS 2/18, 1K cluster) even after new tests,
but only for floppies with physical interleave 1:1.

If you must use 1:2 floppies, for some reason, use standard EAFS 1/400 or
1/18 layout (used by SCO itself and RecoverEDGE). However, the best
combination for any 1:2 emergency set will still be almost 20% slower than
the best combination for 1:1 set.

If you use Lone-Tar's AirBag, avoid 1:2 floppies, because AirBag's layout
(XENIX, 2/18) is considerable slower than the best combinations for 1:2
floppies (e.g. EAFS 1/400).

If you use RecoverEDGE, choose to format floppies during creation process
using system default (1:2) interleave.

> >After this, tls620 loads within 1'56" (still almost twice as slow
> >as v4.2 set) in comparison with the original 7'52".
>
> Script started on Thu Jul 22 10:12:16 1999
> bc 1.04

BTW, 'bc 1.04' works ?
What does it mean ?

> scale=2
> 60 + 56
> 116
> 420 + 52
> 472
> 472 / 116
> 4.06
> quit
>
> 4.06 time slower/faster - depending on your direciton of view.
> Matches with my 'back of the envelope' calculations from above.

Yes, but I still don't understand those 10 revs...

> >I don't know why AirBag needs XENIX support in the kernel on boot
> >floppy. I didn't have to add XENIX support to v5.0.5 kernel on
> >tls620 in order to successfully load this modified emergency set
> >and perform Y2K tests. No, there isn't XENIX support in that v5.0.5
> >kernel already added.
>
> Many systems need an S51 type file system from which to boot.  That
> sort of says something about the complexity of the newer faster
> filesystems on some systems/OSes.

Even HTFS is basically as simple as XENIX/EAFS to read.

Well, I understand necessity of boot file system in SCO v5.0.x to avoid
1024-cylinder limitation rather than '/boot' inability to boot from HTFS,
because HTFS, as I mentioned above, has very small differences as far as
plain reading of files is concerned. The only considerable difference as I
see it is different directory content structure (HTFS uses variable while
S51K family uses fixed), but it's not a big problem really.

But maybe there's some other major limitation for inability to boot from
HTFS, that I don't see (besides 1024 cylinders).

> >I know you weren't referring to emergency floppies at all, I just
> >didn't want to believe I was the only one that experienced this
> >problem.
>
> I hadn't - and I don't now why.  The last emergency set I tested
> and built was on a 300MHz PII, OSR5.0.5, 256MB ram, and 16MB ECC on
> the HD controller.  Loaded just fine in the normal expected time.
> I wonder if it is resources dependant - thought I would think
> most modern hardware should be able to handle this.

Now we know. It's because you use 1:2 floppy disks whereas I became a victim
of 1:1 religion, which eventually turned out to be the best one ever ;-)

PS: I know, my sig separator below isn't correct (it lacks trailing space),
    but my lovely Microsoft Outlook Express thinks that any trailing space
    in the e-mail or news message is useless.

--
Radek Tomis
rts@mediumsoft.cz

Take Control of Your Domain Names

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.