Using block filesystems

Creating ext2/ext3/ext4 filesystems

• To create an empty ext2/ext3/ext4 filesystem on a block device or inside an already-existing image file
  • mkfs.ext2 /dev/hda3
  • mkfs.ext3 /dev/sda2
  • mkfs.ext4 /dev/sda3
  • mkfs.ext2 disk.img
  • To create a filesystem image from a directory containing all your files and directories
  • Use the genext2fs tool, from the package of the same name
  • genext2fs -d rootfs/ rootfs.img
  • Your image is then ready to be transferred to your block device

Mounting filesystem images

• Once a filesystem image has been created, one can access and modifies its contents from the development workstation, using the loop mechanism
• Example: genext2fs -d rootfs/ rootfs.img mkdir /tmp/tst mount -t ext2 -o loop rootfs.img /tmp/tst
• In the /tmp/tst directory, one can access and modify the contents of the rootfs.img file.
• This is possible thanks to loop, which is a kernel driver that emulates a block device with the contents of a file.
• Do not forget to run umount before using the filesystem image!

Creating squashfs filesystems

• Need to install the squashfs-tools package
• Can only create an image: creating an empty squashfs filesystem would be useless, since it's read-only.
• To create a squashfs image:
  • mksquashfs rootfs/ rootfs.sqfs -noappend
  • -noappend: re-create the image from scratch rather than appending to it
• Mounting a squashfs filesystem:
  • mount -t squashfs /dev/ /mnt

Mixing read-only and read-write filesystems

Good idea to split your block storage into:

• A compressed read-only partition (Squashfs)
  • Typically used for the root filesystem (binaries, kernel...). Compression saves space. Read-only access protects your system from mistakes and data corruption.
• A read-write partition with a journaled filesystem (like ext3) Used to store user or configuration data. Guarantees filesystem integrity after power off or crashes.
• Ram storage for temporary files (tmpfs)

Issues with flash-based block storage

• Flash storage made available only through a block interface.
• Hence, no way to access a low level flash interface and use the Linux filesystems doing wear leveling.
• No details about the layer (Flash Translation Layer) they use. Details are kept as trade secrets, and may hide poor implementations.
• Not knowing about the wear leveling algorithm, it is highly recommended to limit the number of writes to these devices.