[bug] scrub on low disk space leads to Transaction aborted

I ran scrub when disk space was low on a btrfs with some raid1 csum errors, on a system with kernel 5.11.0-rc2+. It lead to transaction aborted and rdonly FS. [ 2365.314375] [ cut here ] [ 2365.314385] BTRFS: Transaction aborted (error -28) [ 2365.314470] WARNING: CPU

Re: [PATCH v3 20/22] btrfs: introduce btrfs_subpage for data inodes

Hi Qu, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on kdave/for-next] [also build test WARNING on v5.11-rc2 next-20210108] [cannot apply to btrfs/next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest

Re: btrfs receive eats CoW attributes

I agree that the "--exclude" filter is the most necessary feature for 'btrfs send' but I guess there must be some kind of technical issues which forced the author use "exclude by subvolume" approach. I guess any explicit settings should be transferred by default or there would be no default behavi

cloning a btrfs drive with send and receive: clone is bigger than the original?

­I've got a drive with data, and 3 snapshots of that data. I've transferred all the snapshots to another drive using btrfs send and receive. The send drive has 3.62 GB of data, the receive drive has 4.99 GB of data. It seems like the snapshots don't share data between them that was unchanged. H

Re: cloning a btrfs drive with send and receive: clone is bigger than the original?

09.01.2021 19:01, cedric.dew...@eclipso.eu пишет: > ­I've got a drive with data, and 3 snapshots of that data. I've transferred > all the snapshots to another drive using btrfs send and receive. The send > drive has 3.62 GB of data, the receive drive has 4.99 GB of data. It seems > like the snap

Re: Re: cloning a btrfs drive with send and receive: clone is bigger than the original?

> > How can I transfer the snapshots in such a way that the snapshots only occupy the difference between the snapshots? > > The data on the original drive is organized like this: > /mnt/send/storage/ <= here's all the data > /mnt/send/storage_snapshots/ <= here are the 3 snapshots > > The data o

Re: [RFC][PATCH V4] btrfs: preferred_metadata: preferred device for metadata

On Fri, Jan 08, 2021 at 06:30:49PM +0100, Goffredo Baroncelli wrote: > On 1/8/21 2:05 AM, Zygo Blaxell wrote: > > On Thu, May 28, 2020 at 08:34:47PM +0200, Goffredo Baroncelli wrote: > > > > [...] > > > > I've been testing these patches for a while now. They enable an > > interesting use case th

Re: Re: Raid1 of a slow hdd and a fast(er) SSD, howto to prioritize the SSD?

On Fri, Jan 08, 2021 at 08:29:45PM +0100, Andrea Gelmini wrote: > Il giorno ven 8 gen 2021 alle ore 09:36 ha scritto: > > What happens when I poison one of the drives in the mdadm array using this > > command? Will all data come out OK? > > dd if=/dev/urandom of=/dev/dev/sdb1 bs=1M count = 100? >

Re: Re: Re: cloning a btrfs drive with send and receive: clone is bigger than the original?

I've tested some more. Repeatedly sending the difference between two consecutive snapshots creates a structure on the target drive where all the snapshots share data. So 10 snapshots of 10 files of 100MB takes up 1GB, as expected. Repeatedly sending the difference between the first snapshot and

Re: cloning a btrfs drive with send and receive: clone is bigger than the original?

10.01.2021 10:41, cedric.dew...@eclipso.eu пишет: > I've tested some more. > > Repeatedly sending the difference between two consecutive snapshots creates a > structure on the target drive where all the snapshots share data. So 10 > snapshots of 10 files of 100MB takes up 1GB, as expected. > >