Hi,
the issue I raised in this thread is still not fixed. So, to get things
going, I prepared a patch myself which I will send in a separate email.
The subject will be really fix trim 0 bytes after a device delete.
I would be grateful if you could consider the patch -- with it applied
I finally
Hi,
the issue I raised in this thread is still not fixed. Please, could
someone look into it? A fix should be simple, especially as the issue is
easily reproducable. (In case the information in this thread so far is
not sufficient for that I will happily provide a recipe; just ask.)
Also, I
Hi,
I have seen that in the meantime a patch for this issue has found
its way into 3.3-rc5. Unfortunately with this kernel my filesystem still
says 0 bytes were trimmed, so the bug is not fixed for me.
Now that might just have been caused by the fact that the patch that
went into 3.3-rc5 (as
Hi,
Liu Bo wrote:
Actually I have no idea how to deal with this properly :(
Because btrfs supports multi-devices so that we have to set the
filesystem logical range to [0, (u64)-1] to get things to work well,
while other filesystems's logical range is [0, device's total_bytes].
What's
Hi,
tl;dr: btrfs_trim_fs, IMHO, needs more thorough surgery.
Thanks for providing the new patch. I think it will work in the case
that fstrim is called without specifying a range to trim (that is,
defaulting to the whole filesystem), but I didn't test that yet, sorry.
Instead, I have been
On 02/13/2012 01:01 AM, Lutz Euler wrote:
Hi,
tl;dr: btrfs_trim_fs, IMHO, needs more thorough surgery.
Thanks for providing the new patch. I think it will work in the case
that fstrim is called without specifying a range to trim (that is,
defaulting to the whole filesystem), but I didn't
On 02/06/2012 04:37 AM, Lutz Euler wrote:
... maybe even the block group cache is nonfunctional then?
I am using a btrfs file system, mirrored data and metadata on two SSDs,
and recently tried for the first time to run fstrim on it. fstrim
unexpectedly said 0 bytes were trimmed. strace -T
Hi Liu,
thanks for looking into this!
You wrote:
Would you please test the following patch on your box?
thanks,
liubo
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 77ea23c..b6e2c92 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -7653,9
On 02/09/2012 11:50 PM, Lutz Euler wrote:
Hi Liu,
thanks for looking into this!
You wrote:
Would you please test the following patch on your box?
thanks,
liubo
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 77ea23c..b6e2c92 100644
--- a/fs/btrfs/extent-tree.c
... maybe even the block group cache is nonfunctional then?
I am using a btrfs file system, mirrored data and metadata on two SSDs,
and recently tried for the first time to run fstrim on it. fstrim
unexpectedly said 0 bytes were trimmed. strace -T shows that it spends
only a few microseconds in
10 matches
Mail list logo
