[Courses] [FS] Lesson 5

[Meredydd]

On Wednesday 10 December 2003 13:52, Christine Bussman wrote:
> Looking at my own fstab, I have a few questions.
> (my fstab is located at the end of this email for reference)
>
> 1.  What does the 'notail' option do?  (I have that set on
> several Reiserfs partitions)
This has been answered by others - many thanks.

> 2.  Why does my swap entry have 'none' in the second
> column?  (and for that matter 'sw' in the fourth)
The entry for your swap partition can be pretty much whatever - it 
doesn't really belong in fstab, really. One tells the kernel to use 
swap space by using the "swapon" command, rather than any variation of 
"mount", and almost all the arguments are therefore ignored. The first 
column (device) is valid enough, but the second (mount point) and the 
fourth (options) are completely ignored, as are the numbers in 
positions 5 and 6. For aesthetic reasons, these are filled in with 
plausible-sounding words, which differ according to who put the file 
together, but "/dev/hda2 wibble swap flibble 0 0" would work just as 
well :^)

> 3.  What is the shm entry for?  The explanation in the file
> is gibberish to me.
As I understand it:
SHM is short for SHared Memory - a system by which two different 
processes can "see" the same memory region, and use that to communicate 
between themselves. There are a couple of types of SHM implemented by 
the glibc/Linux combo (not quite sure which bit does which), but one of 
them, called POSIX SHM, requires a "scratch space" for dummy files. You 
see, when a process sets up a region of shared memory, it somehow needs 
to pass a handle to this hunk-o-memory to the process with which said 
memory is to be shared. POSIX SHM does this with a directory path, and 
the current implementation uses dummy files in /dev/shm/. tmpfs is like 
ramfs, which I think I've already mentioned - a "nodev" filesystem 
implementation which does not store anything in persistent storage, 
instead keeping anything that is stored there in memory, and freeing it 
when the filesystem is unmounted. This is perfect for scratch files, 
and so is used by glibc's POSIX SHM implementation.

> 4.  Why the difference in the first column of proc?
Proc, as I have said a few times, is a virtual filesystem - it takes no 
cues from the hardware, or indeed from anywhere other than the kernel's 
internal state. Not only is it marked "nodev" (the device column does 
not need to be a valid path to a block device), but proc takes no 
notice of it. Once again, replace it with the word for the human organ 
of your choosing, the kernel won't care.

> I know some of this may be a distro specific issue, I
> should probably note that I'm using gentoo linux.
All of these variations come under "doesn't matter at all", with the 
exception of POSIX SHM - I don't know whether my glibc even supports 
it. It's pretty rare anyway - most if not all applications you'll see 
at the moment use SYSV shared memory (a different implementation, which 
doesn't bother with /dev/shm/).

> This particular lesson was especially interesting for me,
> because it makes all the 'magic' things I typed in while
> installing make more sense.
That's what it's all about! :^)

Meredydd