Hey Dave, Thanks for clarifying the crash recovery semantics of strictly metadata ordered filesystems. We had a follow-up question in this case.
On Fri, Apr 13, 2018 at 8:16 AM, Amir Goldstein <amir7...@gmail.com> wrote: > On Fri, Apr 13, 2018 at 3:54 PM, Vijay Chidambaram <vi...@cs.utexas.edu> > wrote: >> Hi Amir, >> >> Thanks for the reply! >> >> On Fri, Apr 13, 2018 at 12:52 AM, Amir Goldstein <amir7...@gmail.com> wrote: >>> >>> Not a bug. >>> >>> From man 2 fsync: >>> >>> "Calling fsync() does not necessarily ensure that the entry in the >>> directory containing the file has also reached disk. For that an >>> explicit fsync() on a file descriptor for the directory is also needed." >> >> >> Are we understanding this right: >> >> ext4 and xfs fsync the parent directory if a sym link file is fsync-ed. But >> btrfs does not. Is this what we are seeing? > > Nope. > > You are seeing an unintentional fsync of parent, because both > parent update and symlink update are metadata updates that are > tracked by the same transaction. > > fsync of symlink forces the current transaction to the journal, > pulling in the parent update with it. > > >> >> I agree that fsync of a file does not mean fsync of its directory entry, but >> it seems odd to do it for regular files and not for sym links. We do not see >> this behavior if we use a regular file instead of a sym link file. >> > > fsync of regular file behaves differently than fsync of non regular file. > I suggest this read: > https://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/ > >>> >>> There is a reason why this behavior is not being reproduces in >>> ext4/xfs, but you should be able to reproduce a similar issue >>> like this: >>> >>> >>> 1. symlink (foo, bar.tmp) >>> 2. open bar.tmp >>> 3. fsync bar.tmp >>> 4. rename(bar.tmp, bar) >>> 5. fsync bar >>> ----crash here---- >> Going by your argument that all previous transactions that referenced the file being fsync-ed needs to be committed, should we expect xfs (and ext4) to persist file bar in this case? If that's expected, I'd like to bring to your notice that file bar is not persisted in both xfs and ext4. Is there any other detail we should be considering in this scenario? >> >> I'm guessing xfs/ext4 detect the symlink-fsync pattern and fsync the parent >> dir in our workload, but would miss it because of the rename in the workload >> you provided? >> > > No pattern detecting by xfs/ext4 AFAIK. > rename does not change metadata of victim, so fsync(bar) > may (depending on fs) trigger no metadata transaction commit. > > Thanks, > Amir. ------------------------------------------------------------------------------ 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
