Re: btrfs ops hang indefinitely (process in D state)

Eugene Crosser posted on Sat, 02 Jul 2016 12:49:53 +0300 as excerpted: > Enter the second system. It is a rented physical server in a datacenter > with two hard disks, joined into a single root btrfs (/dev/sd[ab]1 are > swap partitions): > > root@dehost:~# uname -a > Linux dehost

Re: btrfs ops hang indefinitely (process in D state)

Hi Duncan, I pretty much understand the risks and do not need them to be explained to me. When I installed the remote system, the versions where pretty close to the cutting edge. And the problem looks as if it *could* to be the same in 3.13 and in 4.4 kernels. I wrote here to ask advice about

Re: Cannot balance FS (No space left on device)

On 06/13/2016 02:33 PM, Austin S. Hemmelgarn wrote: On 2016-06-10 18:39, Hans van Kranenburg wrote: On 06/11/2016 12:10 AM, ojab // wrote: On Fri, Jun 10, 2016 at 9:56 PM, Hans van Kranenburg wrote: You can work around it by either adding two disks (like Henk

btrfs ops hang indefinitely (process in D state)

Hello, This may be the same problem as "btrfs lockup". I have two systems using btrfs for several years. One is my home desktop, it has root+home ext4 fs on a PCI SSD, and "big stuff" on a btrfs using two hard disks in RAID1 configuration: root@pccross:/export# uname -a Linux pccross

stat() on btrfs reports the st_blocks with delay (data loss in archivers)

There are optimizations in archivers (tar, rsync, ...) that rely on up2date st_blocks info. For example, in GNU tar there is optimization check [1] whether the 'st_size' reports more data than the 'st_blocks' can hold --> then tar considers that file is sparse (and does additional steps). It

Filesystem locks up, also with older kernel on any action after booting into 4.7-rc4 once

I just rebooted a VM into a 4.7 kernel. The joy didn't last long. After 177 seconds the btrfs data partition (root is on ext4) locked up. Worse, it keeps locking up on any action performed even when rebooting it with older kernels again. D: The filesystem initially mounts fine, but then locks

Re: btrfs lockup

On Fri, Jul 1, 2016 at 3:50 PM, Grey Christoforo wrote: > On Fri, Jul 1, 2016 at 9:51 PM, Chris Murphy wrote: >> This is interesting: >> >> Jul 01 11:56:40 kernel: BTRFS info (device nvme0n1p5): relocating >> block group 232511242240 flags 1 >> >>

Re: Filesystem locks up, also with older kernel on any action after booting into 4.7-rc4 once

On Sat, Jul 2, 2016 at 11:34 AM, Hans van Kranenburg wrote: > On 07/02/2016 07:14 PM, Hans van Kranenburg wrote: >> >> I just rebooted a VM into a 4.7 kernel. The joy didn't last long. After >> 177 seconds the btrfs data partition (root is on ext4) locked up.

Re: Cannot balance FS (No space left on device)

On Sat, Jul 2, 2016 at 9:07 AM, Hans van Kranenburg wrote: > > Also, the behaviour of *always* creating a new empty block group before > starting to work (which makes it impossible to free up space on a fully > allocated filesystem with balance) got reverted in: >

Re: Filesystem locks up, also with older kernel on any action after booting into 4.7-rc4 once

On 07/02/2016 09:18 PM, Chris Murphy wrote: On Sat, Jul 2, 2016 at 11:34 AM, Hans van Kranenburg wrote: On 07/02/2016 07:14 PM, Hans van Kranenburg wrote: I just rebooted a VM into a 4.7 kernel. The joy didn't last long. After 177 seconds the btrfs data

Re: Filesystem locks up, also with older kernel on any action after booting into 4.7-rc4 once

On 07/02/2016 07:14 PM, Hans van Kranenburg wrote: I just rebooted a VM into a 4.7 kernel. The joy didn't last long. After 177 seconds the btrfs data partition (root is on ext4) locked up. Worse, it keeps locking up on any action performed even when rebooting it with older kernels again. D: The

btrfs RAID 10 truncates files over 2G to 4096 bytes.

Hi, My setup is that I use one file system for / and /home (on SSD) and a larger raid 10 for /mnt/share (6 x 2TB). Today I've discovered that 14 of files that are supposed to be over 2GB are in fact just 4096 bytes. I've checked the content of those 4KB and it seems that it does contain

Re: Filesystem locks up, also with older kernel on any action after booting into 4.7-rc4 once

On 07/02/2016 09:40 PM, Hans van Kranenburg wrote: On 07/02/2016 09:18 PM, Chris Murphy wrote: On Sat, Jul 2, 2016 at 11:34 AM, Hans van Kranenburg wrote: On 07/02/2016 07:14 PM, Hans van Kranenburg wrote: I just rebooted a VM into a 4.7 kernel. The joy

[PATCH] fs: btrfs: Replace -ENOENT by -ERANGE in btrfs_get_acl()

size contains the value returned by posix_acl_from_xattr(), which returns -ERANGE, -ENODATA, zero, or an integer greater than zero. So replace -ENOENT by -ERANGE. Signed-off-by: Salah Triki --- fs/btrfs/acl.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff

Re: btrfs/113: Assertion failure

On Friday, July 01, 2016 04:25:52 PM Josef Bacik wrote: > On 07/01/2016 12:11 PM, Chandan Rajendra wrote: > > Sorry, Forgot to add the mailing list to CC. Doing it now ... > > > >> While running btrfs/113, I see the following call trace, > >> > >> [ 182.272009] BTRFS: assertion failed: