I would just like to voice my displeasure for disabling XFS support in the kernel. I cannot think of any good reason why this would be done.
Regards
I would just like to voice my displeasure for disabling XFS support in the kernel. I cannot think of any good reason why this would be done.
Regards
Did you mean XFS file system?
Could you tell it been disable in which version?
Yes, the filesystem.
I’m using 32.1 (downloaded yesterday) with the 4.9.140-tegra kernel.
Does install it manually working?
sudo apt-get install xfsprogs
It is not compiled into the kernel, nor as a module.
Have it working now, but had to build a new kernel.
Sucks when all my config files from 28.x are backed up on xfs disks.
@l2normie
Yes, we provide kernel source for the customize kernel.
Yes I was aware of it, and used it to fix.
Do you know why it was removed from the 32.x release?
It was available in the 28.x release as a module.
I’m going to be more reluctant to upgrade in the future. Introducing changes sometimes breaks things, I understand that, but I cannot understand why you would remove file system support you had in an earlier versions.
This change did not provide any improvements (you saved what, 800k?), and for some proportion of users will make adopting 32.x more difficult.
I didn’t see this config in r28.2
Which version have this config?
I need “xfs” too, but I get the error
root@JetsonTX2-0001:/home/doug# modprobe xfs
modprobe: FATAL: Module xfs not found in directory /lib/modules/4.9.140-tegra
Can someone take note for the future that xfs is critical and not a “fringe” case to be missed, and please get that missing binary module to me asap!
Thanks in advance
Doug
stock system:
Linux version 4.9.140-tegra (buildbrain@mobile-u64-2988) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) ) #1 SMP PREEMPT Wed Mar 13 00:30:11 PDT 2019
@Doug
Did you build the kernel like #5?
No, I would need guided walk-through instructions.
I was hoping that future updates would include xfs support by default.
A little annoyed by this as well. Streaming video and processing it through tensorflow, where does that data go? To a disk. What file format works best with sequential writes to a nighthawk hard drive (optimized for sequential writes)? From what I have read, xfs is the best?
Please reply if you know a better filesystem.
I realize this is a long reply, and probably contains far more than you actually need, but the extra (if you are interested) should probably give you confidence once you’ve been through it for a single compile. Skip any part which you are not interested in. Ask for an explanation of any part you are interested in.
A note to consider: If you are not using XFS for the root filesystem, then you only need a module. Using XFS as a root filesystem would be difficult, unless the bootloader itself can handle XFS. The bootloader may need its own driver if information must be retrieved from the root filesystem to boot. For example, if the kernel itself is on the root filesystem, then the bootloader would have to read this and put it in memory before handing over to the kernel. In the default case it is ext4, and the bootloader has no trouble reading ext4. Whether or not it can read XFS I do not know.
In the case of non-rootfs content, e.g., mount an XFS drive somewhere after the kernel is already running and has access to the ext4 filesystem, then the simple copy of a file into the correct location installs the driver and it is fairly hassle free.
Trivia: The kernel looks for those separate driver files (“modules”) in a subdirectory of “/lib/modules/$(uname -r)/”. If you change the kernel version, then all modules must be copied over due to a change in “uname -r”…but if the main kernel is left in place, then adding a module file does not change the “uname -r” and everyone is happy. Before you start, copy the result of the command “uname -r” to see what it is.
You can compile the kernel directly on the TX2, it is quite capable of doing this. In that case, other than install (and even to some extent install), kernel build procedure is just like any other Linux, and module build (a subset of building the kernel) is simple once you’ve done it (the learning curve is fairly low even on a Jetson). Cross compiling (building for arm64 from a PC which is not arm64) adds a lot of the complexity, but if your host is Ubuntu 18.04, then the docs give fairly simple instructions even for this (and you get to skip all flashing for the case of a module addition).
What various documents tend to not emphasize (but should) is that of re-creating the original configuration exactly prior to building the module (docs tend to use a default configuration, “tegra_defconfig”, but the config of the running system is a guarantee of feature matching). When you change base kernel features (integrated features which are not modules), then life can get more complicated. So save a copy of the running system’s “/proc/config.gz” (you can decompress the copy, e.g., “gunzip config_copy.gz”, and then rename it to “.config”). When the “.config” is in the kernel build location (the output location…sometimes this is also the input location, but is discouraged since output to a clean directory simplifies many things), then this kernel will have a feature match to the original. The only left to configure to make it an exact match is the “.config” item “CONFIG_LOCALVERSION”.
This probably seems complicated, and I’ll add some URLs here, but once you do this for a module it’ll seem trivial to you. I do suggest building the full kernel for sanity checks, but you won’t have to install the kernel itself (and no flashing should be involved). Docs for different Jetsons on native compile will be the same aside from some picking the right version. Official docs have what you need for cross compile on an Ubuntu host PC.
https://devtalk.nvidia.com/default/topic/1057246/jetson-tx1/about-kernel/post/5381591/#5381591
https://devtalk.nvidia.com/default/topic/1012382/jetson-tx2/usb-wifi-adapter-s-/post/5290682/#5290682
https://devtalk.nvidia.com/default/topic/1032862/jetson-tx2/a-guide-to-solve-usb-serial-driver-problems-on-tx2/post/5254939/#5254939
https://devtalk.nvidia.com/default/topic/1047880/jetson-tx1/mount-network-folder-samba-cifs/post/5322451/#5322451
Note: Including all modules and features is the land of desktop PCs with relatively unlimited space. Space is limited on an embedded product. You probably don’t need fiber channel RAID drivers, you probably don’t need 10Gbit/s ethernet drivers, drivers for many other file system types, so on. Adding driver modules in the embedded world is just a way of surviving the lack of more disk space and the need for efficiency.