Re: Strange behavior (possible bugs) in btrfs

list. Additionally, if there are more patches queued to address these issues, please let us know. Thanks, Jayashree Mohan Thanks, Jayashree Mohan On Fri, May 11, 2018 at 10:45 AM Filipe Manana wrote: > > On Mon, Apr 30, 2018 at 5:04 PM, Vijay Chidambaram wrote: > > Hi, > > >

Re: Strange behavior (possible bugs) in btrfs

Hi Jeff, On Mon, Apr 30, 2018 at 11:51 AM, Jeff Mahoney wrote: > On 4/30/18 12:04 PM, Vijay Chidambaram wrote: >> 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

Re: Inconsistent behavior of fsync in btrfs

Thanks Chris and Ted for putting down the expected fsync behaviour of btrfs and ext4 clearly. This sort of information is not documented anywhere; it would be really useful if all major filesystems explicitly stated what fsync behavior to expect. Filesystems definitely seem to provide more

Re: Inconsistent behavior of fsync in btrfs

nmount_flakey Thanks for your time! [1] https://github.com/utsaslab/crashmonkey Thanks, Jayashree Mohan On Thu, Apr 26, 2018 at 11:28 AM, Chris Mason <c...@fb.com> wrote: > On 24 Apr 2018, at 20:35, Jayashree Mohan wrote: > >> Hi, >> >> While investigating crash con

Inconsistent behavior of fsync in btrfs

on ext4 and xfs. Please let us know what you feel about such inconsistency. Thanks, Jayashree Mohan -- 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: Directory entry not persisted on a fsync

Hi, A gentle reminder on the above behavior on btrfs : Even on fsync-ing the directory, its entries are not persisted. Could you let us know your thoughts on this? Thanks, Jayashree Mohan On Fri, Apr 20, 2018 at 1:05 PM, Jayashree Mohan <jayashree2...@gmail.com> wrote: > Hi, &g

Directory entry not persisted on a fsync

in the test directory. We expect directory entries to be persisted when the directory inode is fsynced right? Losing file foo doesn't seem to be the right behavior. Thanks, Jayashree Mohan -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message

Re: Hard link not persisted on fsync

Hi Zygo, Thanks for the reply. Here are few responses about btrfs behavior that you had questions about in your email. On Thu, Apr 19, 2018 at 4:41 PM, Zygo Blaxell <ce3g8...@umail.furryterror.org> wrote: > > On Mon, Apr 16, 2018 at 09:35:24AM -0500, Jayashree Mohan w

Re: Hard link not persisted on fsync

comment on why btrfs does not exhibit this behavior, and if it's something you'd want to fix? Thanks, Jayashree Mohan On Mon, Apr 16, 2018 at 9:35 AM, Jayashree Mohan <jayashree2...@gmail.com> wrote: > Hi, > > The following seems to be a crash consistency bug on btrfs, where in &

Hard link not persisted on fsync

to the correct link count of 2 for the above workload. Let us know what you think about this behavior. Thanks, Jayashree Mohan -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo inf

Re: Symlink not persisted even after fsync

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 wrote: > On Fri, Apr 13, 2018 at 3:54 PM, Vijay Chidambaram

Symlink not persisted even after fsync

. Thanks, Jayashree Mohan -- 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: [PATCH] fstests: test btrfs fsync after hole punching with no-holes mode

- however the md5 before and after crash was the same. Could you give more details on this? https://friendpaste.com/1wVAz7hG0U5SgYtZavbJhL https://friendpaste.com/1wVAz7hG0U5SgYtZavxALg Thanks, Jayashree Mohan On Thu, Mar 29, 2018 at 8:45 AM, Filipe Manana <fdman...@kernel.org> wrote: > On

Re: btrfs crash consistency bug : Blocks allocated beyond eof are lost

Mohan On Wed, Feb 21, 2018 at 8:23 PM, Jayashree Mohan <jayashree2...@gmail.com> wrote: > Hi, > > On btrfs (as of kernel 4.15), say we fallocate a file with keep_size > option, followed by fdatasync() or fsync(). If we now crash, on > recovery we see a wrong block cou

btrfs crash consistency bug : Blocks allocated beyond eof are lost

://patchwork.kernel.org/patch/10120293/ [2] https://sourceforge.net/p/linux-f2fs/mailman/message/36104201/ [3] https://github.com/utsaslab/crashmonkey Thanks, Jayashree Mohan 2nd Year PhD in Computer Science University of Texas at Austin. -- To unsubscribe from this list: send the line "unsubs