On Mon, Sep 12, 2016 at 5:56 PM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote: > On 2016-09-12 12:27, David Sterba wrote: >> >> On Mon, Sep 12, 2016 at 04:27:14PM +0200, David Sterba wrote: >>>> >>>> I therefore would like to propose that some sort of feature / stability >>>> matrix for the latest kernel is added to the wiki preferably somewhere >>>> where it is easy to find. It would be nice to archive old matrix'es as >>>> well in case someone runs on a bit older kernel (we who use Debian tend >>>> to like older kernels). In my opinion it would make things bit easier >>>> and perhaps a bit less scary too. Remember if you get bitten badly once >>>> you tend to stay away from from it all just in case, if you on the other >>>> hand know what bites you can safely pet the fluffy end instead :) >>> >>> >>> Somebody has put that table on the wiki, so it's a good starting point. >>> I'm not sure we can fit everything into one table, some combinations do >>> not bring new information and we'd need n-dimensional matrix to get the >>> whole picture. >> >> >> https://btrfs.wiki.kernel.org/index.php/Status > > > Some things to potentially add based on my own experience: > > Things listed as TBD status: > 1. Seeding: Seems to work fine the couple of times I've tested it, however > I've only done very light testing, and the whole feature is pretty much > undocumented. > 2. Device Replace: Works perfectly as long as the filesystem itself is not > corrupted, all the component devices are working, and the FS isn't using any > raid56 profiles. Works fine if only the device being replaced is failing. > I've not done much testing WRT replacement when multiple devices are > suspect, but what I've done seems to suggest that it might be possible to > make it work, but it doesn't currently. On raid56 it sometimes works fine, > sometimes corrupts data, and sometimes takes an insanely long time to > complete (putting data at risk from subsequent failures while the replace is > running). > 3. Balance: Works perfectly as long as the filesystem is not corrupted and > nothing throws any read or write errors. IOW, only run this on a generally > healthy filesystem. Similar caveats to those for replace with raid56 apply > here too. > 4. File Range Cloning and Out-of-band Dedupe: Similarly, work fine if the FS > is healthy.
Virtually all other features work fine if the fs is healthy... > > Other stuff: > 1. Compression: The specific known issue is that compressed extents don't > always get recovered properly on failed reads when dealing with lots of > failed reads. This can be demonstrated by generating a large raid1 > filesystem image with huge numbers of small (1MB) readliy compressible > files, then putting that on top of a dm-flaky or dm-error target set to give > a high read-error rate, then mounting and running cat `find .` > /dev/null > from the top level of the FS multiple times in a row. > 2. Send: The particular edge case appears to be caused by metadata > corruption on the sender and results in send choking on the same file every > time you try to run it. The quick fix is to copy the contents of the file > to another file and rename that over the original. I don't remember having seen such case at least for the last 2 or 3 years, all the problems I've seen/solved or seen fixes from others were all related to bugs in the send algorithm and definitely not any metadata corruption. So I wonder what evidence you have about this. > > -- > 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 -- Filipe David Manana, "People will forget what you said, people will forget what you did, but people will never forget how you made them feel." -- 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
