similar to: [PATCH] Btrfs: fix typo in fallocate to make it honor actual size

Pre-allocate space for data relocation. This can detect ENOPSC condition caused by fragmentation of free space. Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp 2/fs/btrfs/ctree.h 3/fs/btrfs/ctree.h --- 2/fs/btrfs/ctree.h 2010-04-26 17:28:20.493839748 +0800 +++ 3/fs/btrfs/ctree.h 2010-04-26 17:28:20.498830465 +0800 @@ -2419,6 +2419,9 @@ int btrfs_cont_expand(struct inode *inod

Even though we allocate more, we should be updating inode i_size as per the arguments passed Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- Changes from V1: We should update i_size only if actual_len and cur_offset are both larger than i_size. Otherwise if actual_len is < i_size and cur_offset > i_size we may end up setting wrong i_size value

fallocate(2) may allocate large number of file extents, so it''s not good to do it in a single transaction. This patch make fallocate(2) start a new transaction for each file extents it allocates. Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp 6/fs/btrfs/inode.c 7/fs/btrfs/inode.c --- 6/fs/btrfs/inode.c 2009-11-02 10:47:16.106890431 +0800 +++ 7/fs/btrfs/inode.c

The original truncation of btrfs has a bug, that is the orphan item will not be dropped when the truncation fails. This bug will trigger BUG() when unlink that truncated file. And besides that, if the user does pre-allocation for the file which is truncated unsuccessfully, after re-mount(umount-mount, not -o remount), the pre-allocated extent will be dropped. This patch modified the relative

Hello, This patch simplifies the nodatacow checker. If all references were created after the latest snapshot, then we can avoid COW safely. This patch also updates run_delalloc_nocow to do more fine-grained checking. Regards Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp 3/fs/btrfs/ctree.h 4/fs/btrfs/ctree.h --- 3/fs/btrfs/ctree.h 2008-10-27 16:31:51.000000000 +0800 +++

To reproduce the bug: # mount -o nodatacow /dev/sda7 /mnt/ # dd if=/dev/zero of=/mnt/tmp bs=4K count=1 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 0.000136115 s, 30.1 MB/s # dd if=/dev/zero of=/mnt/tmp bs=4K count=1 conv=notrunc oflag=direct dd: writing `/mnt/tmp'': Input/output error 1+0 records in 0+0 records out btrfs_ordered_update_i_size() may return

Btrfs has always had these filler extent data items for holes in inodes. This has made somethings very easy, like logging hole punches and sending hole punches. However for large holey files these extent data items are pure overhead. So add an incompatible feature to no longer add hole extents to reduce the amount of metadata used by these sort of files. This has a few changes for logging and

The function - btrfs_cont_expand() forgot to close the transaction handle before it jump out the while loop. Fix it. Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> --- fs/btrfs/inode.c | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 634dd797..ee57b40 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -3510,15

Rewrite btrfs_drop_extents by using btrfs_duplicate_item, so we can avoid calling lock_extent within transaction. Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- fs/btrfs/ctree.h | 7 +- fs/btrfs/file.c | 659 ++++++++++++++++++++------------------------------- fs/btrfs/inode.c | 27 +-- fs/btrfs/ioctl.c | 3 +- fs/btrfs/tree-log.c | 4 +- 5 files changed, 277

Balance will create reloc_root for each fs root, and it''s going to record last_snapshot to filter shared blocks. The side effect of setting last_snapshot is to break nocow attributes of files. So it turns out that checking last_snapshot does not always ensure that a node/leaf/file_extent is shared. That''s why shared node/leaf needs to search extent tree for number of

We currently have this problem where you can truncate pages that have not yet been written for an ordered extent. We do this because the truncate will be coming behind to clean us up anyway so what''s the harm right? Well if truncate fails for whatever reason we leave an orphan item around for the file to be cleaned up later. But if the user goes and truncates up the file and tries to

Andrew, can you please send this on to Linus and -stable ASAP? It's causing massive problems for our users. On Thu, Aug 12, 2010 at 04:50:59PM -0400, Jeff Moyer wrote: > Hi, > > commit c2c6ca4 (direct-io: do not merge logically non-contiguous > requests) introduced a bug whereby all O_DIRECT I/Os were submitted a > page at a time to the block layer. The problem is that the

We specifically do not update the disk i_size if there are ordered extents outstanding for any area between the current disk_i_size and our ordered extent so that we do not expose stale data. The problem is the check we have only checks if the ordered extent starts at or after the current disk_i_size, which doesn''t take into account an ordered extent that starts before the current

This patch finally gives us full proper -ENOSPC handling for btrfs. Now whenever you do a btrfs_start_transaction, you must specify the number of items you are planning to add/delete/modify. The worst case number of blocks that could be modified by changing that number of items will be calculated and checked against the amount of free space in the space_info where the root you are modifying

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

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

This patch introduce extent buffer cache for every i-node. By this way, we can save the search time and reduce the lock contention of the root because we needn''t search the item from the root of b+ tree. Implementation: - add two pointers of extent buffer into btrfs_inode struct, one for nodes/leaves of fs/file tree, the other for nodes/leaves of the log tree. - add a variant to tell

On Mon, 2024-06-17 at 21:54 +0200, Danilo Krummrich wrote: Hi Timur, thanks for the follow-up on this patch series. On Wed, Jun 12, 2024 at 06:52:53PM -0500, Timur Tabi wrote: The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers that have printf-like logs from GSP-RM and PMU encoded in them. LOGINIT, LOGINTR, and LOGRM are allocated by Nouveau and their DMA addresses are

Unfortunately the DP MST helpers do not have much in the way of debugging utilities. So, let's add some! This adds basic debugging output for down sideband requests that we send from the driver, so that we can actually discern what's happening when sideband requests timeout. Since there wasn't really a good way of testing that any of this worked, I ended up writing simple selftests