Re: [MAINTAINERS/KERNEL SUMMIT] Trust and maintenance of file systems

[Guenter Roeck <linux@roeck-us.net>]

On 9/6/23 17:48, Bagas Sanjaya wrote:
[ ... ]
>> Case in point: After this e-mail, I tried playing with a few file systems.
>> The most interesting exercise was with ntfsv3.
>> Create it, mount it, copy a few files onto it, remove some of them, repeat.
>> A script doing that only takes a few seconds to corrupt the file system.
>> Trying to unmount it with the current upstream typically results in
>> a backtrace and/or crash.
> 
> Did you forget to take the checksum after copying and verifying it
> when remounting the fs?
> 
Sorry, I don't understand what you mean. I didn't try to remount.
The file system images in my tests are pristine, as created with mkfs, and
are marked read-only to prevent corruption. They are also md5 checksum
protected and regenerated before the test if there is a checksum mismatch.
For ntfs, the file system was created with

truncate -s 64M myfilesystem
mkfs.ntfs -F -H 1 -S 16 -p 16 myfilesystem

My tests run under qemu, and always use the -snapshot option.

The "test", if you want to call it that, is a simple

mount "${fstestdev}" /mnt
cp -a /bin /usr /sbin /etc /lib* /opt /var /mnt
rm -rf /mnt/bin
cp -a /bin /usr /sbin /etc /lib* /opt /var /mnt
umount /mnt

This is with a buildroot generated root file system. "cp -a" is a recursive
copy which copies symlinks.

If the file system is ntfs3, the rm command typically fails, complaining
that /mnt/bin is not empty. The umount command typically results in at
least a traceback, and often a crash. Repeating the cp; rm; cp sequence
multiple times quite reliably results in a file system corruption.

The resulting (corrupted or not) file system is discarded after the qemu
session.

Guenter