Hi Joseph,
I carefully ping you again for this issue. Basically, what I see is
that bytes_may_use is always incremented on the btrfs_file_aio_write
path, way before checking for NOCOW flags. As a result, ENOSPC is
returned, even on a fully-allocated NOCOW file. Do you think this can
be improved?
FWIW,
I have found when I am hitting ENOSPC.
btrfs_check_data_free_space() has this code:
...
/* make sure we have enough space to handle the data first */
spin_lock(data_sinfo-lock);
used = data_sinfo-bytes_used + data_sinfo-bytes_reserved +
Hi,
it appears that I found why the COW is happening. The code in the
kernel that triggers this is:
check_committed_ref():
if (btrfs_extent_generation(leaf, ei) =
btrfs_root_last_snapshot(root-root_item))
goto out;
It appears that both extent_generation and
Wade, thanks.
Yes, with the preallocated extent I saw the behavior you describe, and
it makes perfect sense to alloc a new EXTENT_DATA in this case.
In my case, I did another simple test:
Before:
item 4 key (257 INODE_ITEM 0) itemoff 3593 itemsize 160
inode generation 5 transid 5
On Thu, Oct 25, 2012 at 12:35 PM, Alex Lyakas
alex.bt...@zadarastorage.com wrote:
Hi everybody,
I need some help understanding the nodatacow behavior.
I have set up a large file (5GiB), which has very few EXTENT_DATAs
(all are real, not bytenr=0). The file has NODATASUM and NODATACOW
flags
Hi cwillu,
the filesystem has a single subvolume and a single file within it. I
know that ext2 conversion creates an image file that references same
extents, which should cause the COW. I actually used examples from
conversion mkfs code to create this filesystem. Maybe I have some
Hi Alex,
Someone correct me if I am wrong, but I'm pretty sure that the purpose of
'nodatacow' is to prevent the location of extents on the disk itself from
moving, however, it may be necessary to allocate more extents in the metadata
(which I presume are represented by EXTENT_DATA) in order to
Wade, thanks.
Yes, with the preallocated extent I saw the behavior you describe, and
it makes perfect sense to alloc a new EXTENT_DATA in this case.
In my case, I did another simple test:
Before:
item 4 key (257 INODE_ITEM 0) itemoff 3593 itemsize 160
inode generation 5
On 10/25/2012 12:09 PM, Alex Lyakas wrote:
Wade, thanks.
Yes, with the preallocated extent I saw the behavior you describe, and
it makes perfect sense to alloc a new EXTENT_DATA in this case.
In my case, I did another simple test:
Before:
item 4 key (257 INODE_ITEM 0) itemoff 3593
