Disks and File Systems

1. Disks and File Systems Greg Porter V1.0, February 07, 2009

2. Kinds of Disks • Internal or external • “Faster” or “slower” disk • Rotational speed, slower is cheaper (i.e. 5800 RPM vs. 15K) • More or less cache, or other fancy features • Type of interface • “Commodity” inexpensive slower interfaces • IDE, SATA • “Server grade” expensive faster interfaces • SCSI, Fibre Channel, iSCSI • “Plain” simple disk vs. “fancy” non-simple • RAID controller with multiple physical disks • Might be internal or external • Usually presents itself to the host as “one” disk

3. Adding a Disk to a Server • “Commodity” grade components typically need the server to be off • High end “server grade” components sometimes can be added with server running (“hot swappable”) • Proprietary high end Unixes directly support adding or changing components with no down time (i.e. HP-UX has ‘ioscan’ to find new disks) • Regardless, often the easiest and most straightforward method is to turn the server off, add the component, and turn the server back on.

4. Simpler Methods of Using a Disk • Whole disk • Use the whole disk for one file system • Easiest, least flexible • No growth path, no easy way to make the file system larger • Partitioned • “Chop” the disk into pieces or slices • Slightly more flexible • Not so easy to change size of pieces after the fact, but possible • Can’t make a file system that’s larger than the physical disk

5. Fancier Methods of Using a Disk • With a Logical Volume Manager (LVM) • Makes a virtual “logical” disk (volume group), with “logical” pieces (volumes) • Easy to change size of volume group or volumes • Volume groups and volumes can span physical disks, be of arbitrary size • More complicated syntax, perhaps unwieldy or not as reliable • Offers advanced features like instantaneous snapshots of volumes • With software (operating system) RAID • Can use multiple inexpensive disks and make a more reliable disk (software RAID does impose some overhead) • Not as good as a dedicated hardware RAID controller, but not bad (dedicated hardware RAID has better performance) • Possible to “grow” a RAID volume after the fact to accommodate growth

6. So You Have a Disk, Now What? • You could use it “raw” - without a file system • Some applications, notably proprietary database systems (Oracle, Informix, Sybase) will run fastest on raw disks • If you chose to do this, you’re stuck with the app or database vendor’s (lame) tools to manage raw disks • Don’t do this unless speed is the utmost (only) concern • Otherwise, you need a file system

7. So You Need a File System? • Lots to choose from, there are literally dozens of well regarded file systems • Don’t use an experimental one for production, pick one that’s been time tested • Pick one well supported by your distro • All else being equal, a journaling file system is a good choice • More robust • Faster to repair if it does get damaged • Probably shouldn’t pick one whose primary developer is a incarcerated murderer (even if it is cool) • ext3 is an all around suitable choice • Default file system for the Fedora 10 installer

8. Putting the File System on the Disk • Pretty easy, use mkfs –t <type> #mkfs –t ext3 /dev/sdb1 • Mount it #mount /dev/sdb1 /mnt • Make it permanent, add it to /etc/fstab /dev/sdb1 /mnt ext3 defaults 1 2

9. What’s in the New File System? • You’ll see a directory named lost+found drwx------ 2 root root 12288 Jun 22 2008 lost+found • Automatically made • Used during file system check (fsck) operations • If the names of file or directories are lost during fsck they are moved to lost+found, and named after their inodes (a number) • Once something is moved to lost+found it is usually pretty useless. Sometimes, it is still has the correct date, size or owner. It may be the only copy of someone’s term paper or novel. If you’re sufficiently motivated, you might be able to figure out what a lost+found file is and give it back to its rightful owner

10. What Happens When Things Go Wrong? • File systems usually get broken when power is suddenly removed (system is not shut down correctly) • File systems are not put away in an orderly fashion and marked as “clean” • “Dirty” systems are noticed on boot and a fsck is attempted • Truly mangled file systems might fail the automatic fsck • Further manual fscks may be required • *NEVER* fsck a mounted file system • If the root file system needs an fsck, you might have to boot to a CD, and fsck the file system from that • If you have to do a fsck by hand, might as well take the time to do it repeatedly until no errors are noted • Just because the OS thinks the disk is “clean” doesn’t mean that subtle “bit rot” or corruption isn’t happening • Most file systems will force an fsck every so often regardless (every 35 mounts?) • Big file systems (TB+) will take a LOOONG time, even if they are journaled

11. Future Disks and File Systems • Solid State Disks (SSD) • Insanely fast, no moving parts • Insanely expensive (now anyways) • “Enterprise” DRAM based SSD, not cheapo flash based • Used (sparingly) in high performance applications or databases • ext4 is now included in the Linux 2.6.28 kernel • Lots of incremental improvements over ext3 • Will be default file system for Fedora 11 • Sun’s Zetabyte File System (zfs) • Combines best features of LVM, software RAID, and journaling file systems • Too many wickedly cool features to list • Free if you buy Solaris, included in Open Solaris as well, uses the lame CDDL license • Keep your fingers crossed, zfs may make it into Linux yet! • Oracle’s B-Tree File System (btrfs) “butter fs” • Designed to compete with zfs • Open GPL license • Included in the Linux 2.6.29 kernel • Needs more real world testing, still experimental • Watch out Sun!