On Wed, Apr 25, 2018 at 02:30:42PM +0200, Gandalf Corvotempesta wrote: > 2018-04-25 13:39 GMT+02:00 Austin S. Hemmelgarn <ahferro...@gmail.com>: > > Define 'stable'. > > Something ready for production use like ext or xfs with no critical > bugs or with easy data loss. > > > If you just want 'safe for critical data', it's mostly there already > > provided that your admins and operators are careful. Assuming you avoid > > qgroups and parity raid, don't run the filesystem near full all the time, > > and keep an eye on the chunk allocations (which is easy to automate with > > newer kernels), you will generally be fine. We've been using it in > > production where I work for a couple of years now, with the only issues > > we've encountered arising from the fact that we're stuck using an older > > kernel which doesn't automatically deallocate empty chunks. > > For me, RAID56 is mandatory. Any ETA for a stable RAID56 ? > Is something we should expect this year, next year, next 10 years, .... ?
There's not really any ETAs for anything in the kernel, in general, unless the relevant code has already been committed and accepted (when it has a fairly deterministic path from then onwards). ETAs for finding even known bugs are pretty variable, depending largely on how easily the bug can be reproduced by the reporter and by the developer. As for a stable version -- you'll have to define "stable" in a way that's actually measurable to get any useful answer, and even then, see my previous comment about ETAs. There have been example patches in the last few months on the subject of closing the write hole, so there's clear ongoing work on that particular item, but again, see the comment on ETAs. It'll be done when it's done. Hugo. -- Hugo Mills | Nothing wrong with being written in Perl... Some of hugo@... carfax.org.uk | my best friends are written in Perl. http://carfax.org.uk/ | PGP: E2AB1DE4 | dark
signature.asc
Description: Digital signature
