FS#69363 - [f2fs-tools] [linux] [linux-lts] f2fs partition created under 5.10.7-1 unreadable under 5.4.89-1

Attached to Project: Arch Linux
Opened by John (graysky) - Monday, 18 January 2021, 21:04 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 27 January 2021, 23:57 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I booted into 5.10.7-1-ARCH and created a f2fs partition on top of a pre-existing LUKS. After copying over data, I booted into the linux-lts (5.4.89-1) and the partition contents appear unreadable (see below). I ran fsck.f2fs -f /dev/mapper/crypt which completed without indications of damage, yet the contents are still unreadable.

Booting back to 5.10.7 gives normal behavior of files. I am unsure which package is to blame so I tagged all three.

% ls -l /mnt/media
ls: cannot access '/mnt/media/backup': Structure needs cleaning
ls: cannot access '/mnt/media/music': Structure needs cleaning
ls: cannot access '/mnt/media/pics': Structure needs cleaning
total 0
d????????? ? ? ? ? ? backup
d????????? ? ? ? ? ? music
d????????? ? ? ? ? ? pics

Steps to reproduce:

1. Boot to linux package (currently 5.7.10-1)
2. Use cryptsetup to open the LUKS partition (I am using /etc/crypttab to do this with a keyfile).
3. Create a f2fs partition as follows: mkfs.f2fs -l nas -O extra_attr,inode_checksum,sb_checksum /dev/mapper/crypt
4. Copy some data to it
5. Reboot into the lts kernel and try to read the files therein

My LUKS was pre-existing, probably created approx 1 year ago. I do not know if LUKS is a factor in this bug. I have not tried the steps on without LUKS.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Wednesday, 27 January 2021, 23:57 GMT
Reason for closing:  Not a bug
Comment by argo (argo_) - Tuesday, 19 January 2021, 00:44 GMT
This unfortunately is *expected* behavior for f2fs, see [1] for exactly this being one of the reasons openSUSE disabled f2fs & [2] for some (if a tad heated) discussion on the same matter.
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1109665#c0
[2] https://reddit.com/r/openSUSE/comments/enlu5b/speaking_of_lack_of_f2fs_support_by_tumbleweed/fe20niv/
Comment by John (graysky) - Tuesday, 19 January 2021, 01:57 GMT
@argo - thank you very much for the links. I will read through them more thoroughly but at first glace, "Currently the filesystem doesn't have a way to disable mounting of filesystems created with newer kernels, containing on-disk incompatible changes. I have talked with one of the maintainers and they recognize this fact but so far no one is working on this. This is a pretty major since newer images could potentially crash older kernels not being able to properly parse them."

WTF?
Comment by John (graysky) - Tuesday, 19 January 2021, 15:36 GMT
Since this is known, we can close the ticket. I added a warning to the F2FS wiki page: https://wiki.archlinux.org/index.php?title=F2FS&type=revision&diff=649278&oldid=649275

Loading...