BTRFS: The Good, The Bad and The Ugly

[Ric Wheeler]

On 07/14/2011 11:08 AM, JB wrote:
> Ric Wheeler<rwheeler<at>  redhat.com>  writes:
>
>> ...
>> I think that it would be really rare to see pristine, academic algorithms
>> implemented exactly as a non-coding mathematician designed them in code :)
>> ...
> Well, not convinced ... :-)
>
> The algorithm  has to be taken holisticly - it has been designed, tested,
> fine tuned, optimized, tested again, and then submitted to internal rigor,
> and then to external rigor (e.g. of academia, professional community, etc).
>
> When an implementer picks it up, she can not "interpret" it second-handedly.
> She has to take it as a whole. No games !
>
> The algorithm *must* be coded as designed and *not* have programming coding
> bugs.
>
> Next, after coding it (even presumably as originally intended), you have
> to submit it to that same rigor of testing as done by the original algorithm
> inventor.
> And make no mistake, you have to do it repeatedly, at every stage of
> development, iteratively.
>
> Your BTRFS fs's integrity relies on that !
>
> So, no wobbling, strictly as the doctor prescribed :-)
>
> JB
>

Here you are simply wrong.

I have been on the steering committee of the USENIX FAST conference and its 
program chair and do a lot of academic paper reviews.

Every single algorithm ever proposed is endlessly tweaked and twisted both by 
theoreticians and by those implementing them.

(FAST is the most high profile academic conference in the world of file and 
storage systems, see: www.usenix.org for papers and so on)

Going back to btrfs, you need to do more than hand wave and say that it is 
broken. Point at code or experimental results showing a problem or, even better, 
propose a fix to correct a deficiency and back that up with real results.

Ric