Re: Strange behavior (possible bugs) in btrfs

On Mon, Apr 30, 2018 at 11:56 AM, Jayashree Mohan <jayashree2...@gmail.com> wrote: > Hi Jeff, > > On Mon, Apr 30, 2018 at 11:51 AM, Jeff Mahoney <je...@suse.com> wrote: >> On 4/30/18 12:04 PM, Vijay Chidambaram wrote: >>> Hi, >>> >>> We fou

Strange behavior (possible bugs) in btrfs

Hi, We found two more cases where the btrfs behavior is a little strange. In one case, an fsync-ed file goes missing after a crash. In the other, a renamed file shows up in both directories after a crash. Workload 1: mkdir A mkdir B mkdir A/C creat B/foo fsync B/foo link B/foo A/C/foo fsync A

Re: Inconsistent behavior of fsync in btrfs

On Sun, Apr 29, 2018 at 5:16 PM, Theodore Y. Ts'o <ty...@mit.edu> wrote: > On Sun, Apr 29, 2018 at 03:55:39PM -0500, Vijay Chidambaram wrote: >> In the spirit of clarifying fsync behavior, we have one more case >> where we'd like to find out what should be exp

Re: Inconsistent behavior of fsync in btrfs

> On Fri, Apr 27, 2018 at 3:53 PM, Theodore Y. Ts'o wrote: >> On Fri, Apr 27, 2018 at 11:33:29AM -0600, Chris Mason wrote: >>> My goal for the fsync tree log was to make it just do the right thing most >>> of the time. We mostly got there, thanks to a ton of fixes and test cases

Re: Directory entry not persisted on a fsync

Hi all, Any thoughts on this? We completely understand you are all busy and might be traveling, so we only need a simple ack from you: that when we fsync a directory in btrfs, we can expect the contents to get persisted. We understand that is not your highest priority item, and that you will fix

Re: Symlink not persisted even after fsync

On Mon, Apr 16, 2018 at 7:07 PM, Dave Chinner <da...@fromorbit.com> wrote: > On Sun, Apr 15, 2018 at 07:10:52PM -0500, Vijay Chidambaram wrote: >> Thanks! As I mentioned before, this is useful. I have a follow-up >> question. Consider the following workload: >> >>

Re: Symlink not persisted even after fsync

On Mon, Apr 16, 2018 at 12:39 AM, Amir Goldstein <amir7...@gmail.com> wrote: > On Mon, Apr 16, 2018 at 3:10 AM, Vijay Chidambaram <vi...@cs.utexas.edu> > wrote: > [...] >> Consider the following workload: >> >> creat foo >> link (foo, A/bar) >&

Re: Symlink not persisted even after fsync

On Mon, Apr 16, 2018 at 12:52 AM, Theodore Y. Ts'o <ty...@mit.edu> wrote: > On Sun, Apr 15, 2018 at 07:10:52PM -0500, Vijay Chidambaram wrote: >> >> I don't think this is what the paper's ext3-fast does. All the paper >> says is if you have a file system where the fsync

Re: Symlink not persisted even after fsync

so thought I would confirm. The tricky part here is we are not calling fsync() on directory A. In this case, its not a symlink; its a hard link, so I would say the link count for foo should be 2. But btrfs and F2FS show link count of 1 after a crash. Thanks, Vijay Chidambaram http://www.cs.utexas.edu/~vijay/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Symlink not persisted even after fsync

Hi Ted, On Sat, Apr 14, 2018 at 8:30 PM, Theodore Y. Ts'o wrote: > When you open "foo", the restulting file descriptor is not associated > with the symlink. The resulting file descriptor is the exact same > thing you would get if you had instead called: > > fd =

Re: Symlink not persisted even after fsync

n imagine how this can be all be confusing to file-system developers and research groups who work on file systems: without formal documentation, what exactly should they test or support? Clearly current file systems provide more than just POSIX and therefore POSIX itself is not very usef

Re: Symlink not persisted even after fsync

) -> fails but fd = open(symlink, O_CREAT|O_RDWR) -> succeeds (even if symlink already exists) fsync(fd) -> succeeds So perhaps fsync on "symlink" is unsupported behavior that varies from file system to file system? We saw ext4 and xfs had this behavior, so we assumed it to

Re: Symlink not persisted even after fsync

>> >> 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, 2

Re: Symlink not persisted even after fsync

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 I'm guessing xfs/ext4 detect the symlink-fsync pattern and fsync the parent dir in our workload, but would m

Re: CrashMonkey: A Framework to Systematically Test File-System Crash Consistency

don't make any decisions that will prevent us from going the DM target route later. Thanks, Vijay On Wed, Aug 16, 2017 at 3:27 PM, Amir Goldstein <amir7...@gmail.com> wrote: > On Wed, Aug 16, 2017 at 10:06 PM, Vijay Chidambaram <vvija...@gmail.com> > wrote: >> H

Re: CrashMonkey: A Framework to Systematically Test File-System Crash Consistency

key in its current form, which will guide us as to what functionality to add to CrashMonkey to find bugs more effectively. Thanks, Vijay On Wed, Aug 16, 2017 at 8:06 AM, Josef Bacik <jo...@toxicpanda.com> wrote: > On Tue, Aug 15, 2017 at 08:44:16PM -0500, Vijay Chidambaram wrote: >> H