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

Re: extent-tree.c no space left (4.9.77 + 4.16.2)

On 21/04/2018 10:18, Martin Svec wrote: Hi David, this looks like the bug that I already reported two times: https://www.spinics.net/lists/linux-btrfs/msg54394.html https://www.spinics.net/lists/linux-btrfs/msg75104.html The second thread contains Nikolay's debug patch that can confirm if

4.9.83 - btrfs_truncate_inode_items - nospace left -> transid / csum issues.

Hi My volume ran out of space, and that seems to have triggered csum errors. Kernel 4.9.83 % btrfs fi us /backup/ Overall:     Device size:           4.12TiB     Device allocated:           4.12TiB     Device unallocated:           2.00MiB     Device missing:        0.00B     Used:       

4.17-rc1 FS went read-only during balance

TL;DR It seems as regression in 4.17, but I managed to find a workaround to make filesystem rw mountable again. Kernel built from tag v4.17-rc1 btrfs-progs 4.16 Tonight two my machines (PC (ECC RAM) and laptop(non-ECC RAM)) were doing usual weekly balance with this command via cron: btrfs

Re: extent-tree.c no space left (4.9.77 + 4.16.2)

Hi David, this looks like the bug that I already reported two times: https://www.spinics.net/lists/linux-btrfs/msg54394.html https://www.spinics.net/lists/linux-btrfs/msg75104.html The second thread contains Nikolay's debug patch that can confirm if you run out of global metadata reservations

extent-tree.c no space left (4.9.77 + 4.16.2)

Hi, I'm running a 3TiB EBS based (2+1TiB devices) volume in EC2 which contains about 500 read-only snapshots. btrfs-progs v4.7.3 There are two dmesg trace things below. The first one from a 4.9.77 kernel - [ cut here ] BTRFS: error (device xvdg) in