Hi, A gentle reminder on the crash consistency bug we found on f2fs : A zero-range operation with keep_size, followed by a fdatasync() and then a crash, recovers the file with an incorrect size.
We are working on a tool to detect filesystem crash consistency bugs[1], and would be helpful if you acknowledge if the above reported test scenario is considered a bug or not. If not, could you explain why it's okay to do so? [1] https://github.com/utsaslab/crashmonkey Thanks, Jayashree On Wed, Feb 21, 2018 at 12:18 PM, Jayashree Mohan <jayashree2...@gmail.com> wrote: > Hi, > > I am Jayashree Mohan, a PhD student at the University of Texas at > Austin, working with Prof. Vijay Chidambaram. I've been working on the > Crashmonkey project, which is a test harness for file system crash > consistency checks[1]. > > Using CrashMonkey, we stumbled upon the following possible issue with f2fs: > Whenever we do a fallocate zero_range operation with the keep_size > flag, followed by a fdatasync and then crash(power off), on recovery > we see an incorrect file size. This issue aligns with the patch > here[2], except that generic/392 and generic/468 have tested > fallocate_punch_hole and fallocate operations, but not zero_range. > >> On Wed, Nov 15, 2017 at 04:58:33PM +0800, Chao Yu wrote: >>> f2fs can skip isize updating in fsync(), since during mount, f2fs tries >>> to recovery isize according to valid block address or preallocated flag >>> in last fsynced dnode block. >>> >>> However, fallocate() breaks our rule with setting FALLOC_FL_KEEP_SIZE >>> flag, since it can preallocated block cross EOF, once the file is fsynced, >>> in POR, we will recover isize incorrectly based on these fallocated >>> blocks. > > > A simple workload to reproduce this would be : > 1. create foo > 2. Write (8K - 16K) // foo size = 16K now > 3. fsync() > 4. falloc zero_range , keep_size (4202496 - 4210688) // foo size must be 16K > 5. fdatasync() > Crash now > > On recovery, we see that the file size is 4210688 and not 16K, which > violates the semantics of keep_size flag. We have a test case to > reproduce this using CrashMonkey on 4.15 kernel. Try this out by > simply running : > ./c_harness -f /dev/sda -d /dev/cow_ram0 -t f2fs -e 102400 -P -v > tests/generic_468_zero.so > > Do you think, this is a possible corner case that skipped your attention? > Let me know if I am missing some detail. > > [1] https://github.com/utsaslab/crashmonkey > [2] https://sourceforge.net/p/linux-f2fs/mailman/message/36104201/ > > > Thanks, > > Jayashree Mohan > PhD in Computer Science > University of Texas at Austin. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
