[Courses] [FS] Lesson 5

[James Sutherland]

On Wed, 10 Dec 2003 14:43:09 +0000, Telsa Gwynne 
<hobbit at aloss.ukuu.org.uk> wrote:

> On Wed, Dec 10, 2003 at 07:52:32AM -0600 or thereabouts, 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)
>
> I looked in "man fstab" for this and didn't find it. Eventually,
> I found this in "man mount" by wading through it. It was in the
> ReiserFS set of options.
>
>    notail By  default,  reiserfs  stores  small  files  and  file  tails
>           directly  into  its  tree.  This confuses some utilities such 
> as
>           LILO(8).  This option is used to disable packing of  files  
> into
>           the tree.
>
> Quite what a file tail is, I am not sure :)

Almost all file systems work by dividing the disk into chunks called
clusters. Each cluster is then either "in use" or "free". This leaves
a problem: supposing you have 4096 byte (4kb) clusters, and want to
store a 5kb file? Most file systems (FAT, NTFS, ext2) just allocate
2 clusters - wasting the other 3kb of the second cluster.

ReiserFS normally tries to avoid this. Instead, it will allocate a
single cluster to the first 4kb, then put the remaining 1kb "tail"
(whatever is left over which doesn't fill an entire cluster) somewhere
else. That "somewhere else" subdivides clusters, so the other 3kb can
be used by another tail from a different file.

(This feature isn't actually new to ReiserFS; Netware's file system
has had a similar mechanism, known as 'cluster suballocation', since
Netware 4.)

Mounting with the "notail" option disables this feature, so ReiserFS
will behave the same way as other file systems: each file is just
put into one or more entire clusters, wasting more space. There are
two reasons to do this: performance (disabling this cleverness makes
the file system slightly faster, since there's less work involved,
at the expense of wasting more space), and compatibility - some tools,
such as LILO, don't yet understand how ReiserFS stores tails. This
means you need to ensure your kernel (which LILO has to access directly)
is stored conventionally, without tail repacking enabled.

For anything other than /boot - which your boot loader needs to
access, and may have a problem with tail repacking - this seems to
be a straight performance trade-off: do you want slightly faster
performance, at the expense of storage efficiency, or do you want
to wring every last byte out of the disk at the expense of making
the file system slightly slower?

> I don't know the other answers, except that I know that /proc is
> a special filesystem in some way. Perhaps the explanation is in
> the lesson. I haven't read it yet: I am having trouble reaching
> the site.

The difference is that procfs is a sort of "fake" filesystem. Unlike
the others - ext2, FAT, NTFS etc - procfs isn't a way of *storing*
files anywhere; instead, when you access what appears to be a file
under /proc you are really asking the kernel for some information.
That's why the device field is 'none': procfs doesn't use any
underlying disk, it uses the kernel itself.

> Other thing I remember about /proc: people used to tell me never
> to use 'more /proc/somefile' or 'less /proc/somefile'. However,
> it was okay to do 'cat /proc/somefile | less' (or more). For
> reasons I have completely forgotten. I'd love to know what they
> were!

Kernel bug: apparently the kernel got 'upset' with the way more and
less access those files. Tools like cat simply read the file from
beginning to end, which avoids the problem.


James.