* hard links vs. soft/symbolic links

hard links can exist anywhere in the file system
- trying to hard link across f/s, you get the error EXDEV

symlinks can point anywhere: the same or any other f/s
- b/c they get evaluated after the fact and they use a separate inode

HWK: create hard links and symlinks inside and outside the same f/s

* reference counting

when you hard link a file, the inode "num_links" gets incremented

when you call unlink(2), you just decrement num_links by 1
- that's unix calls it "unlink" and not "delete file"

when you remove one name, you "just" decrement the num_links by 1
- when num_links==0, only then you can free up the inode and data blocks

Q: how do you find all the names of a hard linked file?
A: no direct/efficient info in inode to get to all names.
A: will have to do a full scan of the f/s to find all files w/ the same
inode#

HWK: use the find(1) command to scan for all files with a given inode whose
numlinks > 1.

* hard links to non-files

you can only hard link to a regular file
- trying to hard link a non-regular file: EINVAL(?

Some older unix systems allowed you to hard link to a directory
- caused non-local return paths, mistakes by deleting subtrees
  unintentionally

* file systems

A layer above I/O schedulers, below system calls
	and the "VFS" -- Virtual file system layer inside OS

Goal: arrange the data on a specific media, create abstractions for user
system calls to translate to specific media calls (e.g., block reads/writes)

Media types:
- hard disks (block devices, sectors, LBAs)
	- solid state disks (SSDs): also block devices
	- use SCSI, SATA, USB -- protocols
	e.g., ext4
- DVDs CD-ROMs: read-only media
	use older ATA protocols, some variants of SCSI
- floppies: read/write devices, again a different API
	also older ATA/IDE protocols
- network file systems, distributed file system
	using TCP/IP even UDP
	data lives on some other computer(s)
	e.g., nfs, nfs3, nfs4 (Network File System)
- virtual file systems: file systems without any real persistence
	see /proc/filesystems on linux for list of f/s drivers
	procfs: special r/o info from inside the OS
		/proc/cpuinfo, meminfo, self/*
	sysfs: like procfs, but allows you to change kernel params
- memory based file systems (a "ram disk")
	tmpfs, ramfs: very fast
	volatile f/s: data lost on unmount
- file systems in user space (e.g., Linux FUSE)
	100s of examples of FUSE based file systems
	usually slower performance, but very quick to dev
	useful to prototype f/s
	there are commercial user-level file systems
		(e.g. IBM's GPFS aka Spectrum Scale)
- stackable file system (e.g., wrapfs, ecryptfs)
	mounts on top of another (already mounted) directory

Key: the "type" of file system and its implementation largely depends on
what it mounts on: a block device, a network, a floppy, cdrom, ram, another
directory, etc.

* block based file systems

recall: the device provides a mere "array" of LBAs from 0..N

The file system has to decide how to layer the info on LBAs 0..N
- that initialization step is called "format"

file systems have drivers (kernel or user)
- but also a set of user level utilities
	to format (mkfs), mount, unmount,
		check consistency (fsck: file system checker)

Step 1: format a file system
# format a partition/disk for use as ext4
$ mkfs.ext4 [options] /dev/sda1

# format a partition/disk for use as vfat (old windows format)
$ mkfs.vfat [options] /dev/sda2

What does mkfs do:
- where do we place inodes
- how many inodes can we pre-allocate
- where would directories go
- where would data blocks go
- how do I know what blocks/inodes are used or free?

decide how many inodes vs. data/dir blocks you need
how many bitmaps needed for each type of data
where is the start/end/len of each type of data
store all these sizes/offsets in a special "super block"

superblocks are usually stored at LBA 0 (or first LBA of the partition), else
we can't initialize and know what's on an unknown disk that may have been
formatted before.

Superblocks also encode a "magic number", a unique fingerprint for the f/s
in question.  Every f/s is given a different unique string/number.

F/s mount command for file system X checks the superblock to see if it has
the file system X's "fingerprint": else refuse to mount.

But... disk blocks can go bad: hardware, software, media, etc. failures

1. if a data block goes bad, a part (or whole) file's content may not be
readable any more.  OSs may return a block of 0s instead.

2. what if a data block holding a DIRECTORY goes bad?  Some names and
name/inode associations are lost.  The actual inodes and their data blocks
may still be around, but where?

In practice, ...