[sclug] Newbie, partitioning 120Gb HDD - recommendations?

[Tom Dawes-Gamble]

On Tue, 2005-01-18 at 17:48 +0000, David Newcomb wrote:
> Reply to Tom & Alex,
> 
> When the machine boots up the partition table is read.
> For each partition there is a superblock which contains all the inodes
> and addressing information for that partition.

Are you sure?

The superblock has lots of interesting stuff. But *not* inodes. Well not
in System V filesystem or HFS.  (Sorry can't speak for other file
systems.) 

> If you have 1 root partition at the start and (therefore faster outermost
> rim of the disc) then everything that needs to be read or writen can
> be accessed extremly fast. Only 1 super node structure is held in memory.
> All the information can be read in a series of sequental reads.
> 

What is a super node?

> If you have serveral partitions then there is a superblock structure
> for each of the partitions, which are spread across the whole disc.
> Read & write operations cause the disc heads to jump to each of the
> superblock structures for each partition as they read and write.
> 

The superblock is loaded in to memory at when the file system is
mounted. It is immediately writen back with the busy/dirty flag set ON.
It may get written back at other times too.  But it's not read again.
It's in memory and it stays there until the file system is unmounted
when it it written back after all of the dirty blocks have been flushed.
Needless to say it is written back with the busy/dirty flag set OFF.

When you open a file the name has to be mapped to an inode.  This is
done by a routine called namei (Or at least it was when I was taught all
this stuff).  

Lets say you open /etc/passwd first namei has to find "etc" so it read
the / directory. Now everyone knows / is inode 2 of the first filesystem
in the mount table.  So now it's got the inode it can find the address
of the first block of the directory. It then read that block from the
disk and looks to see if etc is listed in that block. if not it goes
back to the inode and gets the second block of the directory and looks
in there. If it's not there it tries the next bock and so on.
Once it finds the "etc" entry it can get the inode (since inode start in
block 2 and they are a fixed size it's easy to calculate the disk
address of an inode in the file system.) if that inode is not already in
the inode table the inode is read into the inode table, then namei
starts reading "etc" for the passwd entry. Once it finds passwd namei
returns saying /etc/passwd is inode N on device /dev/hda1 (say).  So now
the system build you a structure call a File table entry.  The file
table entry has a pointer to the inode and the in memory inode has a
pointer to the device it sits on.

Now if you where to open say /home/user/foo and /home is a separate file
system the when reading / to find home something tells namei that /home
is a mount point. So it know that at this point it has to switch from
say /dev/hda1 to /dev/hda5 and so namei will start from inode 2
in /dev/hda5 and continue the search. and will eventualy
return /home/use/foo is inode n on device /dev/hda5 The file table entry
is built in exactly same way as above.

I doubt you can measure the time taken to cross the mount point.  Since
this only happens on the open it's really not going to effect
performance.

When you do I/O to your file you will read or write N bytes at offset X
in the file.  The filesystem code converts the file offset to a block
address in the file system and passes it on to the device driver.  The
driver then converts the file system block in to a disk block and writes
it to the disk.

> The test [if you can call them that:)] was 2 complete installs on
> the same machine. One with 1 root partition and the other with
> serveral partition. We noted that machine was much faster with just
> one root partition.
> 

What was the test? 

> Be sides the only reason they invented partitioning was because :
> 1. they wanted to address a whole disk using a fixed size address
> (can't remember what size). Remember all that trouble with LBA?

I'm not sure I agree with that.

> 2. The partition segrates all the pieces of disc into managable
> chunks so that if part of the disk becomes currupted that file
> allocation tables are more distributed.
> 

Or that.

> All the rest it overhead.
> 

really?  :-)


Best regards,
Tom.