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 believe so far not even a regression test has been added for this issue.
Here's the state of affairs again, as I mailed previously: > 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 commit 2cac13e41bf5b99ffc426bd28dfd2248df1dfa67) > is the one from Liu Bo's mail <4f3386d8.6010...@cn.fujitsu.com>, which > I already responded to by saying it didn't help my issue. > > But the next patch Liu sent (in the mail > <4f34795b.2020...@cn.fujitsu.com>) also does not help. > At first I responded to that mail: > > > 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. > > I was too optimistic. I have now tested this second patch and still get > "0 bytes were trimmed". Thanks for providing btrfs! Greetings, Lutz -- 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
