On-disk format robustness requirements for new filesystems

Posted Aug 20, 2019 3:55 UTC (Tue) by dvdeug (subscriber, #10998)
Parent article: On-disk format robustness requirements for new filesystems

As for "That's the only way to get the average quality up.", who cares? Maybe it helps Huawei, or maybe not, but making EROFS better doesn't make Linux better for all the users out there who aren't running EROFS. This can work for replacing core parts or even primary filesystems like EXT2 to EXT3 to EXT4, but increasing the average quality by insisting that new filesystems and drivers be better then the ones that are used by most users does little service to most users.

Yes, it's a volunteer system. But if you're concerned about Linux filesystem quality, I'm sure they'll take patches or at least bug reports for existing filesystems. You can push for better quality in core features without taking it out on the new features.

to post comments

On-disk format robustness requirements for new filesystems

Posted Aug 20, 2019 7:52 UTC (Tue) by rsidd (subscriber, #2582) [Link] (2 responses)

I think this is important. If the FS is important for Android, yes, it should be upstreamed. Is there interest from the larger Android community? Are they pushing for upstreaming? If it is only for Huawei's particular fork of Android, why should it be upstreamed?

On-disk format robustness requirements for new filesystems

Posted Aug 20, 2019 8:05 UTC (Tue) by hsiangkao (subscriber, #123981) [Link] (1 responses)

We will definitely upstream to AOSP as well.

On-disk format robustness requirements for new filesystems

Posted Aug 20, 2019 8:11 UTC (Tue) by hsiangkao (subscriber, #123981) [Link]

You can see some prerequisite commits:
https://android-review.googlesource.com/c/platform/system...

and there are some Android commits mentioned about this staging EROFS:
https://android-review.googlesource.com/c/kernel/configs/...

We'd like to upstream to AOSP, and gain wider use of course.

On-disk format robustness requirements for new filesystems

Posted Aug 24, 2019 6:12 UTC (Sat) by buck (subscriber, #55985) [Link] (3 responses)

> As for "That's the only way to get the average quality up.", who cares? Maybe it helps Huawei, or maybe not, but making EROFS better doesn't make Linux better for all the users out there who aren't running EROFS.

If a user plugs a USB drive in his/her machine and it causes the machine to lock up because it has a broken EROFS filesystem on it, that's not cool. It may not be fair, but there's an argument that can be made for not allowing in additional filesystems that widen the gamut of such problems.

That said, i've never written code for a filesystem or anything else nearly as complex that's supposed to deliver as much functionality, so, yes, i can imagine it may put an unrealistic damper on the possibilities for future awesomeness. I'll trust the LKML arbiters to figure it out.

On-disk format robustness requirements for new filesystems

Posted Aug 24, 2019 17:45 UTC (Sat) by alonz (subscriber, #815) [Link] (1 responses)

One could argue that the behavior of mount(8) (automatically trying all filesystem types) is the actual bug, and that its "auto" mode should restrict itself to using filesystems that are actually suitable for use with the current media. (Many filesystem types, EROFS included, could then be defined as supported only on non-removable media by default.)

Alternatively, the filesystem driver may itself verify that the media type is suitable before even reading the superblock.

(Personally I would love it if we could just use lklfuse for all filesystems on removable media… But it looks like nobody support it.)

On-disk format robustness requirements for new filesystems

Posted Aug 25, 2019 1:04 UTC (Sun) by pabs (subscriber, #43278) [Link]

Is lklfuse merged into mainline Linux yet?

On-disk format robustness requirements for new filesystems

Posted Aug 24, 2019 19:04 UTC (Sat) by hsiangkao (subscriber, #123981) [Link]

> If a user plugs a USB drive in his/her machine and it causes the machine to lock up because it has a broken EROFS filesystem on it, that's not cool.

We think that's not cool as well, so we are now addressing and will continue actively addressing it.
But that is not absolute standard on this field ---- one hour, two hours, a day, a month, or forever? by some tool? and that is not filesystem-specific issue, but for all on-disk new features...

Again, please give us some time, not long before it resists almost all malformed images (it can already resist more malformed images than weeks before, and we will fix those reports as quick as what we can... that is our attitude on this...)

On-disk format robustness requirements for new filesystems

Posted Sep 4, 2019 6:42 UTC (Wed) by holgerschurig (guest, #6714) [Link]

> Maybe it helps Huawei,

I think you think too short.

Some of the android things are too specific for android. But some of the concepts needed there are also things that you need in other problem domains (e.g. embedded). And if EROFS is in Linux, then other projects (often in Embedded) might use it as well. It might actually already in use today :-)

> or at least bug reports for existing filesystems.

They are. Hellwig said for XFS that they make great strides for the v5 version, T'so said that for ext4 they work on this, just not with high priority. So warm up your fuzzer and start submitting bug reports :-)