Re: [PATCH v3] fstests: btrfs/159 superblock corruption test case

On Sat, Apr 14, 2018 at 06:43:49AM +0800, Anand Jain wrote: > > > > +# Test if the superblock corruption is handled correctly: > > > +#- Test fsid miss-match (csum ok) between primary and copy > > > superblock > > > +#Fixed by the ML patch: > > > +#btrfs: check if the

Re: Symlink not persisted even after fsync

Hi Dave, Thanks for the reply. I feel like we are not talking about the same thing here. What we are asking is: if you perform fsync(symlink) crash can we expect it to see the symlink file in the parent directory after a crash given we didn't fsync the parent directory? Amir argues we can't

Re: Symlink not persisted even after fsync

On Fri, Apr 13, 2018 at 09:39:27AM -0500, Jayashree Mohan wrote: > 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

Re: [PATCH] btrfs: don't bug_on with enomem in __clear_state_bit

On Fri, Apr 13, 2018 at 04:28:55PM -0400, Josef Bacik wrote: > From: Josef Bacik > > Since we're allocating under atomic we could every easily enomem, so if > that's the case and we can block then loop around and try to allocate > the prealloc not under a lock. > > We also saw

Re: [PATCH] btrfs: don't bug_on with enomem in __clear_state_bit

On Fri, Apr 13, 2018 at 04:52:25PM -0700, Liu Bo wrote: > On Fri, Apr 13, 2018 at 1:28 PM, Josef Bacik wrote: > > From: Josef Bacik > > > > Since we're allocating under atomic we could every easily enomem, so if > > that's the case and we can block then loop

Re: [PATCH] btrfs: don't bug_on with enomem in __clear_state_bit

On Fri, Apr 13, 2018 at 1:28 PM, Josef Bacik wrote: > From: Josef Bacik > > Since we're allocating under atomic we could every easily enomem, so if > that's the case and we can block then loop around and try to allocate > the prealloc not under a lock. > > We

Re: [PATCH v3] fstests: btrfs/159 superblock corruption test case

+# Test if the superblock corruption is handled correctly: +# - Test fsid miss-match (csum ok) between primary and copy superblock +# Fixed by the ML patch: +# btrfs: check if the fsid in the primary sb and copy sb are same +# - Test if the mount fails if the primary

[PATCH] btrfs: don't bug_on with enomem in __clear_state_bit

From: Josef Bacik Since we're allocating under atomic we could every easily enomem, so if that's the case and we can block then loop around and try to allocate the prealloc not under a lock. We also saw this happen during try_to_release_page in production, in which case it's

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

Re: [PATCH for 4.7-rc] btrfs: Only check first key for committed tree blocks

On Fri, Apr 13, 2018 at 06:32:47AM +0800, Qu Wenruo wrote: > When looping btrfs/074 with many cpus (>= 8), it's possible to trigger > kernel warning due to first key verification: > > [ 4239.523446] WARNING: CPU: 5 PID: 2381 at fs/btrfs/disk-io.c:460 > btree_read_extent_buffer_pages+0x1ad/0x210

Re: Symlink not persisted even after fsync

On Fri, Apr 13, 2018 at 08:52:19AM +0300, Amir Goldstein wrote: > On Thu, Apr 12, 2018 at 8:51 PM, Jayashree Mohan > wrote: > > Hi, > > > > We came across what seems to be a crash consistency bug on btrfs and > > f2fs. When we create a symlink for a file and fsync the

Re: [PATCH 11/16] btrfs: kill btrfs_fs_info::volume_mutex

On Fri, Apr 13, 2018 at 01:30:22PM +0800, Anand Jain wrote: > > > > @@ -4569,8 +4560,10 @@ static long btrfs_ioctl_balance(struct file *file, > > void __user *arg) > > /* this is either (2) or (3) */ > > if (!atomic_read(_info->balance_running)) { > >

Re: Symlink not persisted even after fsync

On Fri, Apr 13, 2018 at 3:54 PM, Vijay Chidambaram wrote: > Hi Amir, > > Thanks for the reply! > > On Fri, Apr 13, 2018 at 12:52 AM, Amir Goldstein wrote: >> >> Not a bug. >> >> From man 2 fsync: >> >> "Calling fsync() does not necessarily ensure that

Re: Symlink not persisted even after fsync

Hi Amir, Thanks for the reply! On Fri, Apr 13, 2018 at 12:52 AM, Amir Goldstein 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 >