Re: Battling an issue with btrfs quota

On 01/31/2017 01:15 AM, Philipp Kern wrote: [...] >> 149 00 RW [btrfs-transacti] > > So there's always a running btrfs-transaction. The kernel messages start > off like this: [...] At it turns out, it also OOMs the complete machine after 2h while consuming the available 4 GB RAM

Re: Fresh Raid-1 setup, dump-tree shows invalid owner id

Raid1 is irrelevant, looks like this happen with simple case too. $./mkfs.btrfs tests/test.img $./btrfs-debug-tree tests/test.img possible issue with ./btrfs-debug-tree stdout? On Mon, Jan 30, 2017 at 7:24 AM, Lakshmipathi.G wrote: > After creating raid1: >

Re: raid1: cannot add disk to replace faulty because can only mount fs as read-only.

On 2017-01-28 04:17, Andrei Borzenkov wrote: 27.01.2017 23:03, Austin S. Hemmelgarn пишет: On 2017-01-27 11:47, Hans Deragon wrote: On 2017-01-24 14:48, Adam Borowski wrote: On Tue, Jan 24, 2017 at 01:57:24PM -0500, Hans Deragon wrote: If I remove 'ro' from the option, I cannot get the

Re: Fresh Raid-1 setup, dump-tree shows invalid owner id

> > Yes, the owner is the number of the tree. > > DATA_RELOC_TREE is -9, but then unsigned 64 bits. > -9 + 2**64 > 18446744073709551607L > > So the result is a number that's close to the max or 64 bits. > > You can find those numbers in the kernel source in > include/uapi/linux/btrfs_tree.h

Re: Fresh Raid-1 setup, dump-tree shows invalid owner id

On 01/30/2017 02:54 AM, Lakshmipathi.G wrote: > After creating raid1: > $./mkfs.btrfs -f -d raid1 -m raid1 /dev/sda6 /dev/sda7 > > and using > $./btrfs inspect-internal dump-tree /dev/sda6 #./btrfs-debug-tree /dev/sda6 > > shows possible wrong value for 'owner'? > -- > checksum tree key

Re: btrfs recovery

On 2017-01-28 00:00, Duncan wrote: Austin S. Hemmelgarn posted on Fri, 27 Jan 2017 07:58:20 -0500 as excerpted: On 2017-01-27 06:01, Oliver Freyermuth wrote: I'm also running 'memtester 12G' right now, which at least tests 2/3 of the memory. I'll leave that running for a day or so, but of

Re: [PATCH v3 5/6] btrfs-progs: convert: Switch to new rollback function

On Wed, Jan 25, 2017 at 08:42:01AM +0800, Qu Wenruo wrote: > >> So this implies the current implementation is not good enough for review. > > > > I'd say the code hasn't been cleaned up for a long time so it's not good > > enough for adding new features and doing broader fixes. The v2 rework > >

Re: btrfs recovery

cd / tar -acf boot.tar.gz boot/ ## My subvolumes are at the top level, fstab mounts them specifically, so mount the top level to get access sudo mount -o noatime /mnt ## Take a snapshot of rootfs sudo btrfs sub snap - r /mnt/root /mnt/root.20170130 ## Send it to remote server sudo btrfs send /mnt/root.20

Re: btrfs recovery

<< Hi btrfs experts. Hereby I apply for the stupidity of the month award. >> I have no doubt that I will will mount a serious challenge to you for that title, so you haven't won yet. Why not dd the image back onto the original partition (or another partition identical in size) and see if that

Re: btrfs recovery

Hi Gordon, I'm quite sure this is not a good idea. I do understand, that dd-ing a running system will miss some changes done to the file system while copying. I'm surprised that I didn't end up with some corrupted files, but with no files at all. Also, I'm not interested in restoring the old Suse

Re: btrfs recovery

On 01/30/2017 10:07 PM, Michael Born wrote: > > > Am 30.01.2017 um 21:51 schrieb Chris Murphy: >> On Mon, Jan 30, 2017 at 1:02 PM, Michael Born >> wrote: >>> Hi btrfs experts. >>> >>> Hereby I apply for the stupidity of the month award. >> >> There's still another day

Re: btrfs recovery

On Mon, Jan 30, 2017 at 2:07 PM, Michael Born wrote: > > > Am 30.01.2017 um 21:51 schrieb Chris Murphy: >> On Mon, Jan 30, 2017 at 1:02 PM, Michael Born >> wrote: >>> Hi btrfs experts. >>> >>> Hereby I apply for the stupidity of the month award.

Re: btrfs recovery

Am 30.01.2017 um 22:20 schrieb Chris Murphy: > On Mon, Jan 30, 2017 at 2:07 PM, Michael Born wrote: >> The files I'm interested in (fstab, NetworkManager.conf, ...) didn't >> change for months. Why would they change in the moment I copy their >> blocks with dd? > > They

Re: [PATCH] Btrfs: add another missing end_page_writeback on submit_extent_page failure

On Fri, Jan 13, 2017 at 03:12:31PM +0900, takafumi-sslab wrote: > Thanks for your replying. > > I understand this bug is more complicated than I expected. > I classify error cases under submit_extent_page() below > > A: ENOMEM error at btrfs_bio_alloc() in submit_extent_page() > I first assumed

[PATCH] Btrfs: create a helper to create em for IO

We have similar codes to create and insert extent mapping around IO path, this merges them into a single helper. Signed-off-by: Liu Bo --- fs/btrfs/inode.c | 187 +-- 1 file changed, 72 insertions(+), 115 deletions(-)

Re: btrfs recovery

On 01/30/2017 09:02 PM, Michael Born wrote: > Hi btrfs experts. > > Hereby I apply for the stupidity of the month award. > But, maybe you can help me restoring my dd backup or extracting some > files from it? > > Before switching from Suse 13.2 to 42.2, I copied my / partition with dd > to an

Re: btrfs recovery

On Mon, Jan 30, 2017 at 1:02 PM, Michael Born wrote: > Hi btrfs experts. > > Hereby I apply for the stupidity of the month award. There's still another day :-D > > Before switching from Suse 13.2 to 42.2, I copied my / partition with dd > to an image file - while the

Re: [PATCH] Btrfs: fix leak of subvolume writers counter

On Sat, Jan 28, 2017 at 06:06:54AM +, fdman...@kernel.org wrote: > From: Robbie Ko > > When falling back from a nocow write to a regular cow write, we were > leaking the subvolume writers counter in 2 situations, preventing > snapshot creation from ever completing in

[PATCH] Btrfs: bulk delete checksum items in the same leaf

From: Filipe Manana Very often we have the checksums for an extent spread in multiple items in the checksums tree, and currently the algorithm to delete them starts by looking for them one by one and then deleting them one by one, which is not optimal since each deletion

[PATCH] Btrfs: pass delayed_refs directly to btrfs_find_delayed_ref_head

All we need is @delayed_refs, all callers have get it ahead of calling btrfs_find_delayed_ref_head since lock needs to be acquired firstly, there is no reason to deference it again inside the function. Signed-off-by: Liu Bo --- fs/btrfs/backref.c | 2 +-

[PATCH] Btrfs: remove unused trans in read_block_for_search

@trans is not used at all, this removes it. Signed-off-by: Liu Bo --- fs/btrfs/ctree.c | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c index a426dc8..dd8014a 100644 --- a/fs/btrfs/ctree.c +++

[PATCH] Btrfs: kill trans in run_delalloc_nocow and btrfs_cross_ref_exist

run_delalloc_nocow has used trans in two places where they don't actually need @trans. For btrfs_lookup_file_extent, we search for file extents without COWing anything, and for btrfs_cross_ref_exist, the only place where we need @trans is deferencing it in order to get running_transaction which

btrfs recovery

Hi btrfs experts. Hereby I apply for the stupidity of the month award. But, maybe you can help me restoring my dd backup or extracting some files from it? Before switching from Suse 13.2 to 42.2, I copied my / partition with dd to an image file - while the system was online/running. Now, I can't

Re: btrfs recovery

Am 30.01.2017 um 21:51 schrieb Chris Murphy: > On Mon, Jan 30, 2017 at 1:02 PM, Michael Born wrote: >> Hi btrfs experts. >> >> Hereby I apply for the stupidity of the month award. > > There's still another day :-D > > > >> >> Before switching from Suse 13.2 to 42.2,

Re: [PATCH] Btrfs: fix leak subvol subv_writers conter

On Fri, Oct 7, 2016 at 3:01 AM, robbieko wrote: > From: Robbie Ko > > In run_delalloc_nocow, maybe not release subv_writers conter, > will lead to create snapshot hang. > > Signed-off-by: Robbie Ko I've picked this into my

Hard crash on 4.9.5, part 2

I have an error on this file system I've had in the distant pass where the mount would fail with a "file exists" error. Running a btrfs check gives the following over and over again: Found file extent holes: start: 0, len: 290816 root 257 inode 28472371 errors 1000, some csum missing

[PATCH] Btrfs: fix leak of subvolume writers counter

From: Robbie Ko When falling back from a nocow write to a regular cow write, we were leaking the subvolume writers counter in 2 situations, preventing snapshot creation from ever completing in the future, as it waits for that counter to go down to zero before the snapshot

Re: [PATCH] Btrfs: fix -EINVEL in tree log recovering

On Tue, Oct 11, 2016 at 10:01 AM, robbieko wrote: > From: Robbie Ko > > when tree log recovery, space_cache rebuild or dirty maybe save the cache. > and then replay extent with disk_bytenr and disk_num_bytes, > but disk_bytenr and disk_num_bytes

[PATCH] Btrfs: remove duplicated find_get_pages_contig

This creates a helper to manipulate page bits to avoid duplicate uses. Signed-off-by: Liu Bo --- fs/btrfs/extent_io.c | 202 --- fs/btrfs/extent_io.h | 3 +- 2 files changed, 98 insertions(+), 107 deletions(-) diff --git

Battling an issue with btrfs quota

Hi, my btrfs-based system (~2.5 TiB stored in the filesystem replicated onto on two disks, running kernel 4.9.6-1-ARCH) locked up after I enabled quotas and had a btrfs-size tool running. Now the question is how to recover from that. Whenever I mount the filesystem I end up with btrfs-cleaner and

Re: btrfs recovery

Hello, Micheal, Yes, you would certainly run the risk of doing more damage with dd, so if you have an alternative, use that, and avoid dd. If nothing else works and you need the files, you might try it as a last resort. My guess (and it is only a guess) is that if the image is close to the same

Re: [PATCH] Btrfs: bulk delete checksum items in the same leaf

On Sat, Jan 28, 2017 at 06:06:32AM +, fdman...@kernel.org wrote: > From: Filipe Manana > > Very often we have the checksums for an extent spread in multiple items > in the checksums tree, and currently the algorithm to delete them starts > by looking for them one by one

Re: [PATCH] Btrfs: bulk delete checksum items in the same leaf

On Mon, Jan 30, 2017 at 05:02:45PM -0800, Omar Sandoval wrote: > On Sat, Jan 28, 2017 at 06:06:32AM +, fdman...@kernel.org wrote: > > From: Filipe Manana > > > > Very often we have the checksums for an extent spread in multiple items > > in the checksums tree, and

Re: File system is oddly full after kernel upgrade, balance doesn't help

MegaBrutal posted on Sat, 28 Jan 2017 19:15:01 +0100 as excerpted: > Of course I can't retrieve the data from before the balance, but here is > the data from now: FWIW, if it's available, btrfs fi usage tends to yield the richest information. But it's also a (relatively) new addition to the

Re: btrfs recovery

Michael Born posted on Mon, 30 Jan 2017 22:07:00 +0100 as excerpted: > Am 30.01.2017 um 21:51 schrieb Chris Murphy: >> On Mon, Jan 30, 2017 at 1:02 PM, Michael Born >> wrote: >>> Hi btrfs experts. >>> >>> Hereby I apply for the stupidity of the month award. >> >>

Re: btrfs recovery

Oliver Freyermuth posted on Sat, 28 Jan 2017 17:46:24 +0100 as excerpted: >> Just don't count on restore to save your *** and always treat what it >> can often bring to current as a pleasant surprise, and having it fail >> won't be a down side, while having it work, if it does, will always be >>

Re: [PATCH 8/8] Revert "ext4: fix wrong gfp type under transaction"

On Fri 27-01-17 11:40:42, Theodore Ts'o wrote: > On Fri, Jan 27, 2017 at 10:37:35AM +0100, Michal Hocko wrote: > > If this ever turn out to be a problem and with the vmapped stacks we > > have good chances to get a proper stack traces on a potential overflow > > we can add the scope API around the