Regarding the RAM disk and associated issues...

[krose at theory.lcs.mit.edu (Kyle Rose)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Unfortunately, I had to duck out early, so I didn't get to speak
further with the gentleman who asked about the RAM disk.  Jerry was
right when he spoke about ext2's (the "official" Linux filesystem)
performance, but the issues are more complicated than we could state
in the available time, and so I am offering the following, more
detailed explanation.

FAT (the DOS filesystem) has problems associated with fragmentation,
cluster-size waste, and a poor ability to reconstruct the filesystem
correctly after corruption.  To make up for the last one, write back
caching (in which writes to the file system are first made to memory,
and then are physically written back to disk at some later time) is
severely limited under Windows; otherwise, the registry would crash
far more often than it does even now. =)

ext2 doesn't have any of these problems.  When there is even a
miniscule amount of space available on the disk, files generally are
written in a way that avoids fragmentation.

Under FAT, the size of the cluster allocation table (the misnamed
"FAT," or "file allocation table) is proportional to the size of the
disk; therefore, a disk with very much space and very few files still
has to waste a large portion of the disk (about 5%, typically) on this
table.  (Plus, for redundancy, there are two of them!)  Under ext2,
there is no single cluster allocation table; rather, the system uses
inodes that are (well, essentially) proportional in space usage to the
number of files on the disk.  (This isn't really true, but in the
limit, it's a better approximation.  There is a block bitmap that
records whether a block is being used, but each block takes up only
one bit; not 2 bytes like FAT16.  Check out fs/ext2/balloc.c in the
kernel source for more info.)

Finally, we come to reconstruction of a filesystem after corruption.
Under Linux, this is caused typically by not unmounting a filesystem
before shutting the machine down.  When you reboot, you'll notice that
fsck ("file system check," or "f-suck" as I call it) runs for a while
and might spit out things like "Inode 82476 has zero dtime."
Essentially, ext2 is very good at recovering from typical
power-failure errors, though not as good as journalling file systems;
but that's another story. =)

Well, the long and short of the reconstruction tirade is that Linux
can wait a very long time before physically writing information to the
disk.  The update program typically calls "sync" once every thirty
seconds, but you can kill it and your system will work just fine,
given that the power doesn't randomly cycle like it does here in
Somerville. =) What is interesting, however, is that the buffering
(both read and write-back caching) is done by an interface layer
called the virtual file system (VFS).  (See fs/*.c for VFS source
code.)  Therefore, the FAT code in Linux uses the same buffering
characteristics as the ext2 code, and so, you will see improvements
over Windows in FAT performance under Linux!  This doesn't solve the
former problems (fragmentation and waste) and, of course, FAT doesn't
have permissions; but it IS faster. =)

Kyle


- -- 
Kyle R. Rose                      "They can try to bind our arms,
Laboratory for Computer Science    But they cannot chain our minds
MIT NE43-309, 617-253-5883             or hearts..."
http://web.mit.edu/krr/www/                           Stratovarius
krose at theory.lcs.mit.edu                              Forever Free

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.5 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3Hnm966jzSko6g9wRAipIAJ9MF3WvhpcT12XXtoEorNDEtWbnvwCgkmpE
7mGNhPKsRA4XNgL3s0eZun8=
=ilZ0
-----END PGP SIGNATURE-----
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).