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 +
data_sinfo-
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 gener
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 item
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 tr
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 d
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
inconsistencie
On Thu, Oct 25, 2012 at 12:35 PM, Alex Lyakas
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 set (flags=0x3):
>
