At now btrfs_dedupe_file_range() restricted to 16MiB range for
limit locking time and memory requirement for dedup ioctl()
For too big input rage code silently set range to 16MiB
Let's remove that restriction by do iterating over dedup range.
That's backward compatible and will not change
2017-08-27 23:06 GMT+03:00 Timofey Titovets :
> At now btrfs_dedupe_file_range() restricted to 16MiB range for
> limit locking time and memory requirement for dedup ioctl()
>
> For too big input rage code silently set range to 16MiB
>
> Let's remove that restriction by do
On 2017年08月26日 07:21, Yingyi Luo wrote:
From: yingyil
Add -S/--subvol [NAME] option to configure. It enables users to create a
subvolume under the toplevel volume and populate the created subvolume
with files from the rootdir specified by -r/--rootdir option.
Two
On 2017年08月28日 04:28, Timofey Titovets wrote:
2017-08-27 23:06 GMT+03:00 Timofey Titovets :
At now btrfs_dedupe_file_range() restricted to 16MiB range for
limit locking time and memory requirement for dedup ioctl()
For too big input rage code silently set range to 16MiB
Hey.
Just wondered...
On a number of filesystems I've removed several subvoumes (with -c)...
even called btrfs filesystem sync afterwards... and waited quite a
while (with the fs mounted rw) until no disk activity seems to happen
anymore.
Yet all these fs shows some deleted subvols e.g.:
btrfs
qYdl
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ID=5 is the default, "root" or "toplevel" subvolume which can't be
deleted anyway (at least normally, I am not sure if some debug-magic
can achieve that).
I just checked this (out of curiosity) and all my Btrfs filesystems
report something very similar to yours (I thought DELETED was a made
up