jetpack use ext4 rootfs as deault, but the terminal customer want to use xfs.
I already check some xfs feature:
1、In menuconfig, config_xfs_fs is configed as m; but I can’t find xfs.ko in device system;
2、In sdkmanager environment, such as l4t_flash_from_kernel.sh, with modifying “tool=mkfs.xfs” in do_write_APP(),
and use flash.sh to flash device by the command “./flash.sh jetson-xavier mmcblk0p1” again, but no use.
how can realize xfs rootfs for device system?
thanks for your advices.
Hi,
We don’t have much experience in xfs. Would need other users to share experience about enabling it.
For customizing rootfs, you may refer to
Root File System — Jetson Linux Developer Guide documentation
You can developer your rootfs based on minimal flavor rootfs.
Whenever the boot stages do not directly understand the filesystem type you will need an initrd. The initrd acts as a kind of adapter. However, in those cases, one usually would still put “/boot” in ext4, and then the rest of the system as XFS. I can’t specifically answer, but will provide some information you might find useful.
The bootloader is its own o/s. It’s one job is to eventually set up the environment, and then overwrite itself with the Linux kernel. If the Linux kernel is in binary format in a partition, then that isn’t a problem since the bootloader merely loads it as data at some physical address, and then transfers execution to that address.
When the kernel is in “/boot”, then this means that in addition to the bootloader requiring knowledge of reading the binary content (such as an eMMC or SD card driver), it also needs to understand the filesystem on top of this. The existing boot software understands ext4.
Then, with the kernel loaded, kernel modules are loaded. Those are somewhere under “/lib/modules”, and if the kernel is on ext4 in “/boot”, but the module needed to understand XFS is in “/lib/modules” on XFS, you get the old dilemma whereby to understand XFS you must first understand XFS, and it just doesn’t work.
There is another filesystem type which all bootloaders will understand, and that is the initial ramdisk (initrd). This is just a tree structure, and it doesn’t really understand things like permissions and more advanced content. The kernel too will always understand this. Since both kernel and boot stages understand this, any gap in knowledge can be fixed by putting it in the initrd. So for example the kernel module supporting XFS can be put in the “/lib/modules” of the initrd, and the ext4 kernel can then load the XFS module from initrd, and understand XFS. From then on, the rest of “/” can be loaded from XFS, including other modules in “/lib/modules”.
Whenever the kernel runs it runs only a single program: init. In Ubuntu that happens to be a symbolic link pointing at systemd. It is init which makes all other programs and boot steps occur. A typical initrd will place a minimal init into the initrd (part of the reason what it is called an initial ramdisk, or initrd). Most this is just bash scripting under a very limited bash shell. Eventually this will perform a chroot (or something similar) to transfer the “/” from being a synthetic partition in RAM to an actual disk (e.g., mmcblk0p1).
If the kernel and device tree is read from a partition instead of “/boot”, and if the kernel has the XFS capability integrated into the kernel (not in the form of a module), and if everything needed is from that binary partition (including arguments to be passed to the kernel upon startup), not even “/boot” needs to be ext4. However, I don’t know if the NVIDIA boot content works well without extlinux.conf, which is the main place to add arguments. Even in the case of the device tree’s “chosen->bootargs”, this is usually created as an environment setup, and then the extlinux.conf includes this via a macro in the “APPEND” key/value pair: The “${cbootargs}” is how device tree content becomes part of the kernel command line.
If you are putting the kernel and device tree and extlinux.conf in “/boot”, then an initrd will have no trouble with adding the XFS module. Or if the “/boot” kernel already has XFS integrated, then everything can be XFS…but that is if and only if the bootloader can load that content. Thus you are back to either putting some content in “/boot” as ext4, or else needing the bootloader itself to understand XFS (you can get the kernel and device tree in a partition, but I don’t know how to put extlinux.conf anywhere except “/boot”).
If NVIDIA knows of a way to put extlinux.conf into a binary partition, and not in “/boot”, or if NVIDIA knows of a way to manually set kernel arguments even without extlinux.conf, then XFS would not be nearly as much of a problem. Or, if you can leave “/boot” as ext4, this too is not much of a problem if XFS is integrated into the kernel Image. Once you separate that into a separate module you are forced into the world of initial ramdisks.
Most people want XFS for large file performance, e.g., multimedia. If this is the reason for your customer wanting XFS, then they probably won’t care that “/boot” remains ext4. If NVIDIA knows of a way to pass arguments and everything from partitions, without referring to “/boot” during boot, then it is also relatively simple by changing the flash arguments and customizing the kernel.
although I don’t understand fully, I still will appreciate to your detailed explanation.
Thanks a lot.
It’s complicated, but the gist is that each step of boot needs to understand part of gathering content from the next stage. Eventually the boot code (and then Linux kernel) needs to be able to understand XFS. If something is “stock”, then the boot content and default kernel will have no problem. In the case of something custom, e.g., XFS, then typically you will do this: