Re: Add udev-md-raid-safe-timeouts.rules

Adding linux-usb@ and linux-scsi@ (This email does contain the thread initiating email, but some replies are on the other lists.) On Mon, Apr 16, 2018 at 5:43 AM, Austin S. Hemmelgarn wrote: > On 2018-04-15 21:04, Chris Murphy wrote: >> >> I just ran into this: >> >>

Re: [PATCH v2 10/10] btrfs: qgroup: Use independent and accurate per inode qgroup rsv

On Mon, Apr 16, 2018 at 04:53:10PM +0900, Misono Tomohiro wrote: > On 2018/04/12 22:13, David Sterba wrote: > > On Tue, Apr 03, 2018 at 03:30:34PM +0800, Qu Wenruo wrote: > >> I didn't see this patch merged in your misc-next branch but only the > >> remaining patches. > >> > >> However without

Re: Kernel unaligned access at ... btrfs_real_readdir+0x51c/0x718 [btrfs]

On Mon, Apr 16, 2018 at 04:52:16PM +0200, René Rebe wrote: > I just installed the latest #t2sde test build on a sparc64 system with > btrfs rootfs - you know, just for the fun of testing, and in contrast > to my x86 and ppc systems I get tons of unaligned access warnings, in > the form of: > > [

Re: Add udev-md-raid-safe-timeouts.rules

On Mon, 16 Apr 2018, Chris Murphy wrote: > Adding linux-usb@ and linux-scsi@ > (This email does contain the thread initiating email, but some replies > are on the other lists.) > > On Mon, Apr 16, 2018 at 5:43 AM, Austin S. Hemmelgarn > wrote: > > On 2018-04-15 21:04,

Re: [PATCH 1/4] btrfs: Use while loop instead of labels in __endio_write_update_ordered

On Wed, Apr 11, 2018 at 11:21:17AM +0300, Nikolay Borisov wrote: > Currently __endio_write_update_ordered uses labels to implement > what is essentially a simple while loop. This makes the code more > cumbersome to follow than it actually has to be. No functional > changes. No xfstest regressions

Re: Kernel unaligned access at ... btrfs_real_readdir+0x51c/0x718 [btrfs]

Hi, On 04/16/2018 06:48 PM, David Sterba wrote: The warnings are valid, there's unaligned access introduced by patch 23b5ec74943f44378b68c0edd8e210a86318ea5e btrfs: fix readdir deadlock with pagefault The directory entries (struct dir_entry) are copied to a temporary buffer as they fit, ie.

Re: [PATCH v4 3/4] btrfs: Refactor btrfs_ioctl_snap_destroy() by using btrfs_delete_subvolume()

On Wed, Apr 11, 2018 at 02:20:49PM +0900, Misono Tomohiro wrote: > Use btrfs_delete_subvolume() to refactor btrfs_ioctl_snap_destroy(). > The permission check is still done in btrfs_ioctl_snap_destroy(). Also, > call of d_delete() is still required since btrfs_delete_subvolume() > does not call

Re: [PATCH 2/4] btrfs: Fix lock release order

On Wed, Apr 11, 2018 at 11:21:18AM +0300, Nikolay Borisov wrote: > Locks should generally be released in the oppposite order they are > acquired. Generally lock acquisiton ordering is used to ensure > deadlocks don't happen. However, as becomes more complicated it's > best to also maintain proper

Re: [PATCH 3/4] btrfs: Consolidate error checking for btrfs_alloc_chunk

On Wed, Apr 11, 2018 at 11:21:19AM +0300, Nikolay Borisov wrote: > The second if is really a subcase of ret being less than 0. So > introduce a generic if (ret < 0) check, and inside have another if > which explicitly handles the -ENOSPC and any other errors. No > functional changes. > >

Re: Symlink not persisted even after fsync

On Mon, Apr 16, 2018 at 12:52 AM, Theodore Y. Ts'o 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 of a file persisted >> only

Re: Symlink not persisted even after fsync

On Mon, Apr 16, 2018 at 12:39 AM, Amir Goldstein wrote: > On Mon, Apr 16, 2018 at 3:10 AM, Vijay Chidambaram > wrote: > [...] >> Consider the following workload: >> >> creat foo >> link (foo, A/bar) >> fsync(foo) >> crash >> >> In this case, after

Re: Add udev-md-raid-safe-timeouts.rules

And then there are SAN devices managed by multipath, were the timeouts should maybe even lower. I know in the scsi layer there are some extra retries going on and that that actual timeout hits at 5x the base timeout. So there kind of is a soft timeout on SAN devices at the base timeout.

Re: btrfs fails to mount after power outage

On 12 April 2018 at 00:25, Qu Wenruo wrote: > I'm curious about what's the underlying disk? It's an Samsung PM951 NVMe SSD. > Is it plain physical device? Or have other layers like bcache/lvm? btrfs on LUKS >> btrfs check > Full output please.

Re: [PATCH] btrfs: Do super block verification before writing it to disk

On 04/16/2018 10:02 AM, Qu Wenruo wrote: There are already 2 reports about strangely corrupted super blocks, where csum type and incompat flags get some obvious garbage, but csum still matches and all other vitals are correct. This normally means some kernel memory corruption happens,

Kernel unaligned access at ... btrfs_real_readdir+0x51c/0x718 [btrfs]

Hi, I just installed the latest #t2sde test build on a sparc64 system with btrfs rootfs - you know, just for the fun of testing, and in contrast to my x86 and ppc systems I get tons of unaligned access warnings, in the form of: [0.00] Btrfs loaded, crc32c=crc32c-generic [0.00]

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

On Sat, Apr 14, 2018 at 02:49:52AM +0200, David Sterba wrote: > 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

Re: Add udev-md-raid-safe-timeouts.rules

On 16/04/18 12:43, Austin S. Hemmelgarn wrote: On 2018-04-15 21:04, Chris Murphy wrote: I just ran into this: https://github.com/neilbrown/mdadm/pull/32/commits/af1ddca7d5311dfc9ed60a5eb6497db1296f1bec This solution is inadequate, can it be made more generic? This isn't an md specific

Hard link not persisted on fsync

Hi, The following seems to be a crash consistency bug on btrfs, where in the link count is not persisted even after a fsync on the original file. Consider the following workload : creat foo link (foo, A/bar) fsync(foo) ---Crash--- Now, on recovery we expect the metadata of foo to be persisted

Unclear `btrfs subvolume snapshot` command

Hi, I'm using # btrfs version btrfs-progs v4.16 In btrfs-subvolume(8), I find the description of the `snapshot` command unclear: snapshot [-r] |[/] I find the preference of `|` is unclear. From the text passage If only is given, the subvolume will be named the basename

Re: Add udev-md-raid-safe-timeouts.rules

On 2018-04-15 21:04, Chris Murphy wrote: I just ran into this: https://github.com/neilbrown/mdadm/pull/32/commits/af1ddca7d5311dfc9ed60a5eb6497db1296f1bec This solution is inadequate, can it be made more generic? This isn't an md specific problem, it affects Btrfs and LVM as well. And in fact

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

On Mon, Apr 9, 2018 at 2:05 PM, Eryu Guan wrote: > On Sun, Apr 08, 2018 at 09:46:24AM +0100, Filipe Manana wrote: >> On Sun, Apr 8, 2018 at 8:46 AM, Eryu Guan wrote: >> > On Wed, Mar 28, 2018 at 12:55:30PM +0100, fdman...@kernel.org wrote: >> >> From:

Re: [PATCH] btrfs: Do super block verification before writing it to disk

On Mon, Apr 16, 2018 at 10:02:27AM +0800, Qu Wenruo wrote: > There are already 2 reports about strangely corrupted super blocks, > where csum type and incompat flags get some obvious garbage, but csum > still matches and all other vitals are correct. > > This normally means some kernel memory

Re: Kernel unaligned access at ... btrfs_real_readdir+0x51c/0x718 [btrfs]

On Mon, Apr 16, 2018 at 09:55:45PM +0200, René Rebe wrote: > Hi, > > On 04/16/2018 06:48 PM, David Sterba wrote: > > The warnings are valid, there's unaligned access introduced by patch > > > > 23b5ec74943f44378b68c0edd8e210a86318ea5e > > btrfs: fix readdir deadlock with pagefault > > > > The

Re: [PATCH 0/15] Review uuid_mutex usage

On Thu, Apr 12, 2018 at 10:29:23AM +0800, Anand Jain wrote: > uuid_mutex lock is not a per-fs lock but a global lock. The main aim of > this patch-set is to critically review the usage of this lock, and delete > the unnecessary once. By doing this we improve the concurrency of > device operations

Re: [PATCH v2] btrfs: Fix race condition between delayed refs and blockgroup removal

On Wed, Apr 11, 2018 at 10:59:09AM +0300, Nikolay Borisov wrote: > When the delayed refs for a head are all run, eventually > cleanup_ref_head is called which (in case of deletion) obtains a > reference for the relevant btrfs_space_info struct by querying the bg > for the range. This is

Re: [PATCH 4/4] btrfs: Rewrite retry logic in do_chunk_alloc

On 16.04.2018 21:53, David Sterba wrote: > On Wed, Apr 11, 2018 at 11:21:20AM +0300, Nikolay Borisov wrote: >> do_chunk_alloc implements logic to detect whether there is currently >> pending chunk allocation (by means of space_info->chunk_alloc being >> set) and if so it loops around to the

Re: [PATCH] btrfs: Do super block verification before writing it to disk

On Mon, Apr 16, 2018 at 09:00:38PM +0800, Qu Wenruo wrote: > > > On 2018年04月16日 20:55, Anand Jain wrote: > > > > > > On 04/16/2018 10:02 AM, Qu Wenruo wrote: > >> There are already 2 reports about strangely corrupted super blocks, > >> where csum type and incompat flags get some obvious

Re: [PATCH 4/4] btrfs: Rewrite retry logic in do_chunk_alloc

On Wed, Apr 11, 2018 at 11:21:20AM +0300, Nikolay Borisov wrote: > do_chunk_alloc implements logic to detect whether there is currently > pending chunk allocation (by means of space_info->chunk_alloc being > set) and if so it loops around to the 'again' label. Additionally, > based on the state

Proposal

Hello Greeetings to you please did you get my previous email regarding my investment proposal last week friday ? MS.Zeliha ömer faruk zeliha.omer.fa...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org

Re: [PATCH 08/16] btrfs: add sanity check when resuming balance after mount

On 04/04/2018 02:34 AM, David Sterba wrote: Replace a WARN_ON with a proper check and message in case something goes really wrong and resumed balance cannot set up its exclusive status. The check is a user friendly assertion, I don't expect to ever happen under normal circumstances. Also

Re: error: redefinition of 'struct btrfs_ioctl_defrag_range_args

Thanks. If you see no problems, then its probably locally on my machine. On Thu, Apr 12, 2018 at 5:10 PM, David Sterba wrote: > On Wed, Apr 11, 2018 at 01:22:23PM +0300, Ilan Schwarts wrote: >> Hi >> While trying to compile my kernel module on suse 12.2 kernel >>

Re: [PATCH v2 10/10] btrfs: qgroup: Use independent and accurate per inode qgroup rsv

On 2018/04/12 22:13, David Sterba wrote: > On Tue, Apr 03, 2018 at 03:30:34PM +0800, Qu Wenruo wrote: >> I didn't see this patch merged in your misc-next branch but only the >> remaining patches. >> >> However without this patch, btrfs qgroup reserved space will get >> obviously increased as

Why btrfsInode -> root is null

Hi all, I maintain kernel module on top of VFS. When action executes, e.g vfs_rename, i get dentry object. I need to get the fsid from the dentry object. Since I maintain the same code for alot of suse distro and kernels (11.4, 12.0, 12.1, 12.2), i have many #if macros, My question is in SLES

Re: btrfs fails to mount after power outage

On 2018年04月17日 00:07, Tom Vincent wrote: > On 12 April 2018 at 00:25, Qu Wenruo wrote: >> I'm curious about what's the underlying disk? > > It's an Samsung PM951 NVMe SSD. > >> Is it plain physical device? Or have other layers like bcache/lvm? > > btrfs on LUKS > >>>

Re: Symlink not persisted even after fsync

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: > > creat foo > link (foo, A/bar) > fsync(foo) > crash > > In this case, after the file system recovers, do we

Re: [PATCH v2 10/10] btrfs: qgroup: Use independent and accurate per inode qgroup rsv

On 2018年04月17日 01:27, David Sterba wrote: > On Mon, Apr 16, 2018 at 04:53:10PM +0900, Misono Tomohiro wrote: >> On 2018/04/12 22:13, David Sterba wrote: >>> On Tue, Apr 03, 2018 at 03:30:34PM +0800, Qu Wenruo wrote: I didn't see this patch merged in your misc-next branch but only the

Re: [PATCH v4 3/4] btrfs: Refactor btrfs_ioctl_snap_destroy() by using btrfs_delete_subvolume()

On 2018/04/17 2:53, David Sterba wrote: > On Wed, Apr 11, 2018 at 02:20:49PM +0900, Misono Tomohiro wrote: >> Use btrfs_delete_subvolume() to refactor btrfs_ioctl_snap_destroy(). >> The permission check is still done in btrfs_ioctl_snap_destroy(). Also, >> call of d_delete() is still required

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

On Mon, Apr 16, 2018 at 12:28:59PM +0100, Filipe Manana wrote: > On Mon, Apr 9, 2018 at 2:05 PM, Eryu Guan wrote: > > On Sun, Apr 08, 2018 at 09:46:24AM +0100, Filipe Manana wrote: > >> On Sun, Apr 8, 2018 at 8:46 AM, Eryu Guan wrote: > >> > On Wed, Mar

Re: [PATCH] btrfs: Do super block verification before writing it to disk

On 2018年04月16日 20:55, Anand Jain wrote: > > > On 04/16/2018 10:02 AM, Qu Wenruo wrote: >> There are already 2 reports about strangely corrupted super blocks, >> where csum type and incompat flags get some obvious garbage, but csum >> still matches and all other vitals are correct. >> >> This

Re: [PATCH 13/16] btrfs: remove redundant read-only check from btrfs_cancel_balance

On 04/04/2018 02:34 AM, David Sterba wrote: Balance cannot be started on a read-only filesystem and will have to finish/exit before eg. going to read-only via remount. Cancelling does not need to check for that. In case the filesystem is forcibly set to read-only after an error, balance will

[PATCH] btrfs: Do super block verification before writing it to disk

There are already 2 reports about strangely corrupted super blocks, where csum still matches but extra garbage gets slipped into super block. The corruption would looks like: -- superblock: bytenr=65536, device=/dev/sdc1 - csum_type

Re: Symlink not persisted even after fsync

On Mon, Apr 16, 2018 at 7:07 PM, Dave Chinner 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: >> >> creat foo >> link (foo, A/bar)

[PATCH] btrfs: add comment about BTRFS_FS_EXCL_OP

Adds comments about BTRFS_FS_EXCL_OP to existing comments about the device locks. Signed-off-by: Anand Jain --- fs/btrfs/volumes.c | 16 1 file changed, 16 insertions(+) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index