Skip to content

Latest commit

 

History

History
123 lines (103 loc) · 4.8 KB

README.md

File metadata and controls

123 lines (103 loc) · 4.8 KB
Raw

wtfs

wtfs version Build status GitHub license

What the fxck filesystem for Linux

Licensed under GPLv3

中文说明见 README.zh_CN.md

How to use it

Before compiling, you need to install build essentials and Linux kernel header files of proper version to enable kernel module building (gcc version >= 4.6 and linux version >= 3.11). In addition, uuid and libmount header files are required to build mkfs.wtfs and statfs.wtfs now.

# only for Debian derivatives
$ sudo apt-get install build-essential linux-headers-`uname -r`
$ sudo apt-get install uuid-dev libmount-dev

After meeting the build prerequisite, clone this repository.

$ git clone https://github.com/chaosdefinition/wtfs.git

First compile the whole project and load the module into kernel.

$ cd wtfs && make
$ sudo insmod build/wtfs.ko

Then create a directory (here we name it ~/wtfs-test) as the mount point.

$ mkdir ~/wtfs-test

Use a block device (here we name it /dev/sda), do format on it and mount it on the directory we just created.

$ sudo ./mkfs.wtfs -f /dev/sda
$ sudo mount -t wtfs /dev/sda ~/wtfs-test

Or you can also use a loop device to make a regular file accessible as a block device, but this is not recommended (because calling mark_buffer_dirty may block on a loop device, causing write operation to be considerably slow). Create a 4GB (any size, but not too small, will fit) regular file (here we name it wtfs.img), do format and then mount it.

$ dd bs=4096 count=1048576 if=/dev/zero of=wtfs.img
$ ./mkfs.wtfs -f wtfs.img
$ sudo mount -o loop -t wtfs wtfs.img ~/wtfs-test

After mount, you can do anything you want within this filesystem. Just have fun.

To unmount an instance and remove the module from kernel, do following.

$ sudo umount ~/wtfs-test
$ sudo rmmod wtfs

If you want to see specific usage of mkfs.wtfs, do following.

# manpage for mkfs.wtfs
$ man man/man8/mkfs.wtfs.8

How to debug

Follow the above steps except that replace the command make with make debug, by doing which the binaries will contain debugging symbols and the macro DEBUG will also be defined. Then you can use external debuggers like gdb to debug mkfs.wtfs and statfs.wtfs.

However, debugging the module is something more primitive since so far I haven't used any kernel debugger. What I do is merely have a look at module's output log... So if you have any more advanced method, please use it.

How to make a test

Simply type the command make test after you build it. It doesn't matter whether you are using debug mode or not.

Following binary utilities are required by test scripts, but it doesn't matter either if you don't have them in your PATH, in which case some parts of the test will be skipped.

  • udisksctl from package udisks2
  • gvfs-mount from package gvfs-bin
  • uuid from package uuid
  • bc from package bc

Physical disk layout of wtfs

Version 0.6.0

wtfs layout

  • Size of each block is 4096 bytes.
  • Size of each inode is 64 bytes.
  • Size of each dentry is 64 bytes.
  • Block 0 is boot loader block (unused now).
  • Block 1 is super block.
  • Block 2 is the first inode table and the head of inode table chain. Because we use the last 8 bytes of a block as a pointer to another block, an inode table can contain a maximum of 63 inodes. The number of inode tables is determined by the number of inode bitmaps.
  • Block 3 is the first block bitmap and the head of block bitmap chain. For the same reason, a block bitmap can state at most 4088 * 8 blocks. The number of block bitmaps is determined by device size.
  • Block 4 is the first inode bitmap and the head of inode bitmap chain. For the same reason again, an inode bitmap can state at most 4088 * 8 inodes. The number of inode bitmaps is one by default and cannot be changed before version 0.5.0. Since version 0.5.0, it can be set to a value within a reasonable range (bigger than zero and smaller than a specific value relating to device size) when doing format.
  • Blocks from 5 are data blocks. Data blocks also have their last 8 bytes to be a pointer except symbolic links. For symlinks, they always contain only one data block each, the first 2-byte-long word of which records the length of symlink content that is stored in the remaining 4094 bytes. So the max length of symlink content is therefore 4094 bytes.

Contact me

Please send me email if you have any question or suggestion: [email protected]