similar to: [PATCH] Btrfs: proper metadata -ENOSPC handling

Reserve metadata space for extent tree, checksum tree and root tree Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp 8/fs/btrfs/ctree.h 9/fs/btrfs/ctree.h --- 8/fs/btrfs/ctree.h 2010-04-18 10:26:38.327697818 +0800 +++ 9/fs/btrfs/ctree.h 2010-04-18 10:30:01.883697869 +0800 @@ -682,21 +682,15 @@ struct btrfs_space_info { u64 bytes_reserved; /* total bytes the allocator has

Hello, Ok here are all my fsync changes, including the fix for the put_transaction stuff that I posted earlier. I figure it'll be easier to just commit it as one thing then each individual peice. The additional thing that I did was add a radix tree that tracks the current outstanding transactions. I also added a field to the in memory btrfs inode that keeps track of the last transaction

This patch changes some BUG_ON() to the error return. (but, most callers still use BUG_ON()) Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com> --- fs/btrfs/ctree.c | 3 ++- fs/btrfs/disk-io.c | 5 ++++- fs/btrfs/extent-tree.c | 25 ++++++++++++++++++------- fs/btrfs/file-item.c | 3 ++- fs/btrfs/inode-map.c | 3 ++- fs/btrfs/ioctl.c | 5 ++++-

We calculate timeout (either 1 or MAX_SCHEDULE_TIMEOUT) based on whether num_writers > 1 or should_grow at the top of the loop. Then, much much later, we wait for that timeout if either num_writers or should_grow is true. However, it''s possible for a racing process (calling btrfs_end_transaction()) to decrement num_writers such that we wait forever instead of for 1. Fix this by

There are several bugs at error path of create_snapshot() when the transaction commitment failed. - access the freed transaction handler. At the end of the transaction commitment, the transaction handler was freed, so we should not access it after the transaction commitment. - we were not aware of the error which happened during the snapshot creation if we submitted a async transaction

Document those places in the btrfs code which are BUGing on non-fatal error conditions that should be handled by proper error paths. This makes it easier to distinguish between what needs fixing versus which BUG_ON''s we might want to keep (to trap code bugs, unexpected inconsistencies, etc). Do this with a trivial macro, ''btrfs_fixable_bug_on'' which just defines to

This check for a user transaction is a bogus: fsync() with an open user transaction is verboten. If the caller is the same process who started a user transaction, and this is a different file, we will deadlock. If it''s the same file, this check means we won''t deadlock, but the transaction will be prematurely closed out. Any user transaction ioctl users should be careful to

When testing with max_extents=4k, we enospc out really really early. The reason for this is we really overwhelm the system with our worst case calculation. When we try to flush delalloc, we don''t want everybody to wait around forever, so we wake up the waiters when we''ve done some of the work in hopes that its enough work to get everything they need done. The problem with this

Hi everyone, This patchset is the latest approach I''m using for the Ceph storage daemon to keep track of which data has safely committed to disk. The basic idea is to not use the (problematic) user transaction ioctls at all. Instead, the daemon quiesces its own write requests, initiates an async snapshot, and then continues. The snapshot approach is nice because it provides rollback.

Hi Chris, This is the extent of my current queue of Btrfs snapshot/subvol/commit stuff. Most of these were posted several months ago. Can be sent upstream during this merge window? Not having this functionality is becoming a bit of a roadblock for our efforts to keep the Ceph data in a consistent state. These patches are also available from

On Fri, Feb 28, 2020 at 06:25:36PM +0100, Jean-Philippe Brucker wrote: > Platforms without device-tree do not currently have a method for > describing the vIOMMU topology. Provide a topology description embedded > into the virtio device. > > Use PCI FIXUP to probe the config space early, because we need to > discover the topology before any DMA configuration takes place, and the

We have been using bytes_reserved for metadata reservations, which is wrong since we use that to keep track of outstanding reservations from the allocator. This resulted in us doing a lot of silly things to make sure we don''t allocate a bunch of metadata chunks since we never had a real view of how much space was actually in use by metadata. There are a lot of fixes in here to make this

We have been using bytes_reserved for metadata reservations, which is wrong since we use that to keep track of outstanding reservations from the allocator. This resulted in us doing a lot of silly things to make sure we don''t allocate a bunch of metadata chunks since we never had a real view of how much space was actually in use by metadata. There are a lot of fixes in here to make this

> From: Jean-Philippe Brucker > Sent: Saturday, February 29, 2020 1:26 AM > > Platforms without device-tree do not currently have a method for > describing the vIOMMU topology. Provide a topology description embedded > into the virtio device. > > Use PCI FIXUP to probe the config space early, because we need to > discover the topology before any DMA configuration takes

> From: Jean-Philippe Brucker > Sent: Saturday, February 29, 2020 1:26 AM > > Platforms without device-tree do not currently have a method for > describing the vIOMMU topology. Provide a topology description embedded > into the virtio device. > > Use PCI FIXUP to probe the config space early, because we need to > discover the topology before any DMA configuration takes

> From: Jean-Philippe Brucker > Sent: Saturday, February 29, 2020 1:26 AM > > Platforms without device-tree do not currently have a method for > describing the vIOMMU topology. Provide a topology description embedded > into the virtio device. > > Use PCI FIXUP to probe the config space early, because we need to > discover the topology before any DMA configuration takes

When btrfs_start_transaction() fails, we should call btrfs_std_error() properly for filesystem to readonly. (in this patch, forced readonly framework is used) Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com> --- fs/btrfs/file.c | 1 + fs/btrfs/inode.c | 34 +++++++++++++++++++++++++++------- fs/btrfs/ioctl.c | 11 ++++++++++- fs/btrfs/relocation.c | 4 +++-

I''ve been working to try to improve the write-ahead log''s performance, and I found that the bottleneck addresses in the checksum items, especially when we want to make a random write on a large file, e.g a 4G file. Then a idea for this suggested by Chris is to use sub transaction ids and just to log the part of inode that had changed since either the last log commit or the last

fs_info->last_trans_committed is a 64bits variant, we might get a wrong value on the 32bit machines if we access it directly. Fix it by atomic operation. Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> --- fs/btrfs/ctree.h | 2 +- fs/btrfs/disk-io.c | 2 +- fs/btrfs/file.c | 2 +- fs/btrfs/ioctl.c | 2

I fixed a problem where we weren''t reserving space for an orphan item when we had to fallback to using the global reserve for an unlink, but I introduced another problem. I was migrating the bytes from the transaction reserve to the global reserve and then releasing from the global reserve in btrfs_end_transaction(). The problem with this is that a migrate will jack up the size for the