Re: 40TB volume taking over 16 hours to mount, any ideas?

[Duncan <1i5t5.duncan@cox.net>]

Mitch Harder posted on Sat, 09 Aug 2014 23:57:19 -0500 as excerpted:

> On Sat, Aug 9, 2014 at 11:21 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> So by the time of actual .0 release, [the kernel] really is quite
>> stable, and no longer development kernel.
>>
> I can't say I've observed that to be the case with Btrfs.  I know there
> is a core group of developers working very hard on testing the Btrfs
> updates in the _rc kernels, but once that .0 kernel hits the streets,
> the extra exposure to all the various combinations of hardware and
> options has been know to discover new issues.  I think this is nearly
> unavoidable given the pace of Btrfs development.

That's because, despite the (IMO premature) recent removal of all the 
warnings to the contrary, btrfs itself isn't stable yet.  I'd argue that 
a 3.x.0 kernel is in general more stable than any btrfs to date, tho in 
both cases there's certainly corner-cases that are markedly more unstable 
(if they run at all) than the general case.

Which means at this point it's a rather dramatic stability inversion to 
be afraid of 3.x.0 kernels while all the while running btrfs on the same 
systems.

(It is worth noting, however, that say a temperature sensor driver or a 
camera driver could get away with the level of working-for-most-people-
most-of-the-time level of stability that is btrfs at this point, and be 
considered reasonably stable.  But people tend to be rather more 
conservative when it's their data, not just a temperature sample or a 
camera shot here or there, going missing, and filesystems therefore have 
a rather higher threshold definition to hit for really being stable.  And 
that's as it /should/ be, because it /is/ people's data in the balance.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman