btrfs crash consistency bug : Blocks allocated beyond eof are lost

https://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 "u

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

Mohan On Wed, Feb 21, 2018 at 8:23 PM, Jayashree Mohan 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 count and all the blocks allocated &

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: [PATCH] generic: add test for fsync after shrinking truncate and rename

Hi Amir, > I went back to look at similar fsync tests by Filipe: > generic/{106,107,335,336,341,342,343,348,498,501,502,509,510,512} > > I found some alleged subtle mistakes about SOMC assumptions. > > generic/336 does: > touch $SCRATCH_MNT/a/foo > ln $SCRATCH_MNT/a/foo $SCRATCH_MNT/b/foo_link > t

Re: [PATCH] fstests: test btrfs fsync after hole punching with no-holes mode

tree - 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 wrote: > On Wed, Mar 28, 2018 at

Re: [PATCH] fstests: test btrfs fsync after hole punching with no-holes mode

On Mon, Apr 2, 2018 at 9:24 AM, Filipe Manana wrote: > On Thu, Mar 29, 2018 at 7:55 PM, Jayashree Mohan > wrote: >> Hi Filipe, >> >> I tried running the xfstest above on kernel 4.15.0 and I haven't been >> able to hit the bug. The xfstest passes clean for me.

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: 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 > wrote: >> Hi Amir, >> >> Thanks for the

Hard link not persisted on fsync

cover 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 majordom

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 wrote: > Hi, > > The following seems to be a crash consistency bug on btrfs, where in > the link count is not

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 wrote: > > On Mon, Apr 16, 2018 at 09:35:24AM -0500, Jayashree Mohan wrote: > > Hi, > > > > The follo

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 me

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 wrote: > Hi, > > We came across a scena

Inconsistent behavior of fsync in btrfs

bove tests pass 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: Inconsistent behavior of fsync in btrfs

nt _unmount_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 wrote: > On 24 Apr 2018, at 20:35, Jayashree Mohan wrote: > >> Hi, >> >> While investigating crash consistency b

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 guarante

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 renamed file shows up i