1# MinFS
2
3MinFS is a simple, unix-like filesystem built for Zircon.
4
5It currently supports files up to 4 GB in size.
6
7## Using MinFS
8
9### Host Device (QEMU Only)
10
11 * Create a disk image which stores MinFS
12```shell
13(Linux)
14$ truncate --size=16G blk.bin
15(Mac)
16$ mkfile -n 16g blk.bin
17```
18 * Execute the run zircon script on your platform with the '--' to pass
19   arguments directly to QEMU and then use '-hda' to point to the file. If you
20   wish to attach additional devices, you can supply them with '-hdb', '-hdc,
21   and so on.
22```shell
23$ ./scripts/run-zircon-x64 -- -hda blk.bin
24```
25
26### Target Device (QEMU and Real Hardware)
27
28**WARNING**: On real hardware, "/dev/class/block/..." refers to **REAL** storage
29devices (USBs, SSDs, etc).
30
31**BE CAREFUL NOT TO FORMAT THE WRONG DEVICE.** If in doubt, only run the
32following commands through QEMU.
33The `lsblk` command can be used to see more information about the devices
34accessible from Zircon.
35
36 * Within zircon, 'lsblk' can be used to list the block devices currently on
37   the system. On this example system below, "/dev/class/block/000" is a raw
38   block device.
39```
40> lsblk
41ID  DEV      DRV      SIZE TYPE           LABEL
42000 block    block     16G
43```
44 * Let's add a GPT to this block device.
45```
46> gpt init /dev/class/block/000
47...
48> lsblk
49ID  DEV      DRV      SIZE TYPE           LABEL
50002 block    block     16G
51```
52 * Now that we have a GPT on this device, let's check what we can do with it.
53   (NOTE: after manipulating the gpt, the device number may change. Use lsblk
54   to keep track of how to refer to the block device).
55```
56> gpt dump /dev/class/block/002
57blocksize=512 blocks=33554432
58Partition table is valid
59GPT contains usable blocks from 34 to 33554398 (inclusive)
60Total: 0 partitions
61```
62 * "gpt dump" tells us some important info: it tells us (1) How big blocks are,
63   and (2) which blocks we can actually use.
64   Let's fill part of the disk with a MinFS filesystem.
65```
66> gpt add 34 20000000 minfs /dev/class/block/002
67```
68 * Within Zircon, format the partition as MinFS. Using 'lsblk' you should see
69   a block device which is the whole disk and a slightly smaller device which
70   is the partition. In the above output, the partition is device 003, and would
71   have the path '/dev/class/block/003'
72```
73> mkfs <PARTITION_PATH> minfs
74```
75
76 * If you want the device to be mounted automatically on reboot, use the GPT
77   tool to set its type. As we did above, **you must** use 'lsblk' **again**
78   to locate the entry for the disk. We want to edit the type of the zero-th
79   partition.  Here we use the keyword 'DATA' to set the type GUID, but if you
80   wanted to use an arbitrary GUID you would supply it where 'DATA' is used.
81```
82> gpt edit 0 type DATA <DEVICE_PATH>
83```
84
85 * On any future boots, the partition will be mounted automatically at /data.
86
87 * If you don't want the partition to be mounted automatically, you can update
88   the visibility (or GUID) of the partition, and simply mount it manually.
89```
90> mount <PARTITION_PATH> /data
91```
92
93 * Any files written to "/data" (the mount point for this GUID) will persist
94   across boots. To test this, try making a file on the new MinFS volume,
95   rebooting, and observing it still exists.
96```
97> touch /data/foobar
98> dm reboot
99> ls /data
100```
101
102 * To find out which block device/file system is mounted at each subdirectory
103   under a given path, use the following command:
104```
105> df <PATH>
106```
107