BTRFS: The Good, The Bad and The Ugly
Ric Wheeler
rwheeler at redhat.com
Thu Jul 14 11:03:30 UTC 2011
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
More information about the devel
mailing list