should btrfs reserve some space for root, so a normal user can't cause "no space left" problems?

I have done a test where I filled up an entire btrfs raid 1 filesystem as a normal user. Then I simulated a failing drive. it turned out I was unable to replace the drive, as raid1 need free space on both drives. See this mail for details [1] I can understand the technical reasoning behind the

[PATCH] btrfs: make btrfs_dirty_inode() to always reserve metadata space

There are several qgroup flush related bugs fixed recently, all of them are caused by the fact that we can trigger qgroup metadata space reservation holding a transaction handle. Thankfully the only situation to trigger above reservation is btrfs_dirty_inode(). Currently btrfs_dirty_inode() will

Re: [PATCH] btrfs-progs: align btrfs receive buffer to enable fast CRC

Alignment to cache line is a great idea. I guess compiler can issue faster memcpy version. Thank you! On Wed, Jan 06, 2021 at 01:16:35PM +0100, David Sterba wrote: > > On Sat, Dec 26, 2020 at 02:46:06PM -0700, shng...@gmail.com wrote: > > From: Sheng Mao > > > > To use optimized CRC implementi

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

On Thu, May 28, 2020 at 08:34:47PM +0200, Goffredo Baroncelli wrote: > > [the previous patches sets called this mode ssd_metadata] > > Hi all, > > This is an RFC; I wrote this patch because I find the idea interesting > even though it adds more complication to the chunk allocator. > > The initi

[PATCH] btrfs: Prevent nowait or async read from doing sync IO

When reading from btrfs file via io_uring I get following call traces: [<0>] wait_on_page_bit+0x12b/0x270 [<0>] read_extent_buffer_pages+0x2ad/0x360 [<0>] btree_read_extent_buffer_pages+0x97/0x110 [<0>] read_tree_block+0x36/0x60 [<0>] read_block_for_search.isra.0+0x1a9/0x360 [<0>] btrfs_search_slo

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

On Tue, Jan 05, 2021 at 07:19:14PM +0100, wrote: > >> I was expecting btrfs to do almost all reads from the fast SSD, as both > the data and the metadata is on that drive, so the slow hdd is only really > needed when there's a bitflip on the SSD, and the data has to be > reconstructed. > > > II

[PATCH v3] btrfs: shrink delalloc pages instead of full inodes

Commit 38d715f494f2 ("btrfs: use btrfs_start_delalloc_roots in shrink_delalloc") cleaned up how we do delalloc shrinking by utilizing some infrastructure we have in place to flush inodes that we use for device replace and snapshot. However this introduced a pretty serious performance regression.

Re: synchronize btrfs snapshots over a unreliable, slow connection

On 07/01/2021 03:09, Zygo Blaxell wrote: ... > I would only attempt to put the archives into long-term storage after> > verifying that they produce correct output when fed to btrfs receive;> otherwise, you could find out too late that a months-old archive was> damaged, incomplete, or incorrect, an

Re: [PATCH v2] btrfs: shrink delalloc pages instead of full inodes

On Mon, Jan 04, 2021 at 03:39:50PM -0500, Josef Bacik wrote: > Commit 38d715f494f2 ("btrfs: use btrfs_start_delalloc_roots in > shrink_delalloc") cleaned up how we do delalloc shrinking by utilizing > some infrastructure we have in place to flush inodes that we use for > device replace and snapshot

Re: KASAN: null-ptr-deref Write in start_transaction

syzbot suspects this issue was fixed by commit: commit f30bed83426c5cb9fce6cabb3f7cc5a9d5428fcc Author: Filipe Manana Date: Fri Nov 13 11:24:17 2020 + btrfs: remove unnecessary attempt to drop extent maps after adding inline extent bisection log: https://syzkaller.appspot.com/x/bise