[RFC] Other Filesystem Support

[gdallasdye]

I'm wondering if we can work in support for the xfs filesystem? I'm filing this as an issue, since there are multiple ways we we can do it, each one building on the last:

1. Kconfig changes. Adds read write support for the filesystem. Select all options except the debugging stuff. Remember to build it in and not as a module.
2. The above plus changing reference in fstab from 'ext4' to 'auto'.
3. The above plus adding a reference to 'xfsprogs' in the build dependencies in the readme.
4. The above plus changing the buildFilesystem.sh and/or InstallPrawnOS.sh scripts to allow the builder or user to choose their preferred filesystem. This could happen in several ways: 4a. Add comments to the scripts. Makes it easier for those either building from scratch, or running nano on the InstallPrawnOS.sh script before running it. Implies the filesystem option may not be ready for production; comments are welcome. 4b. Add a choice menu to the install script to allow a user to choose their filesystem. Implies options have undergone extensive stress testing, and cause no issues.

There is a warning message that looks like an error message at first. It's that the current version of the xfs filesystem cannot handle timestamps beyond 2038. Strictly speaking, this is not our issue as I have also seen this same message on my x64 workstation, running Oracle's Unbreakable kernel. I read a blog of theirs saying that they will address that in a future version of the filesystem.

Both option fours could come in handy for those at home wanting to experiment with their favorite filesystems. This issue could also double for discussion about other non ext4 filesystems.

Although I have been using xfs as my default filesystem for the past four or so months, I would not recommend going above option 3 (or possibly 4a) at this time. This is because I am not a filesystem expert. At this time, I can say it "Works For Me" for both normal web browsing, and causally stress testing it building PrawnOS. Haven't seen any errors in the log files either. Here's a link documenting what I do to enable it. Do with that as you will.

When the scripts runs the mkfs.xfs command, I skip adding the '-B 1024' option, as I assume the filesystem knows how to work efficiently. Also worth keeping in mind that the two mkfs commands use different capitalization.

[SolidHal]

I don't see any reason against 1-3, besides in an attempt to keep the kernel small. I don't think adding the xfs driver will be too much of a negative impact on size though :)

Out of curiosity, whats the advantage of xfs on a low powered system like this?

[gdallasdye]

I'm not sure of the technical advantage, although I have read that xfs can outperform in some circumstances at the same threadcount.

It's also interesting because it was not originally developed for linux or arm/x86 (made for IRIX on mips chips) so both of those non-nativenesses could make it an reliable fallback option in case a future revision of extfs has some controversial change. Also has posix and selinux compliance.

It's also the default option of my workstation's os. Hate to sound like a salesperson, but both the upstream (Red Hat) and the clone with the option of paying for it (Oracle) as well as the upstream's preferred clone (CentOS); they all are (sometimes) financially motivated to use a default filesystem as that does not cause issues for their paying customers. That matters to the end user in me, that someone cares enough to say "Shut up and take my money!"

The "storytime" reason being that one day one of my motherboards died, and I needed to read a luks+xfs drive. That was the same time initial luks support landed in PrawnOS; no more missing module problem. It was also quicker to add xfs to the C201 than to delete 32/34 intel me partitions on my other chromebooks boot chip, like I'd previously did to my workstation, and was putting off on my C720. Then after a couple of months of it not causing problems, I started using it for my main filesystem. Still no problem.

I never did give the size a thought, thanks for the input. Last time I checked, the kernel was still about 12mb, 9mb compressed, out of the 32mb kernel partition. Out of curiosity, is this related to the veyron-mini project? I've been naming my builds as veyron instead of c201, as we're no longer theoretically limited to c201. Still researching how to escape the limits of depthcharge based firmware, using PrawnOS as a known good launchpoint. I did see a mention to an IRC a couple of weeks ago, but couldn't find an address. Is there a place to talk of such slightly offtopic things related to the project?

I'll give it a test build a run with it as a module instead. I think that may be the quickest and easiest way to measure how many kilobytes it uses. That does seem like the correct methodology to measure it's size, right? In theory, it should take the same or less space in kernel due to whatever compression is being used, but don't quote me on that.

There is also a part of me that's curious about other people's usage of non-default filesystems. I've heard good things about F2FS and have heard Btrfs no longer eats your data.