BTRFS: The Good, The Bad and The Ugly

[Josef Bacik]

On Thu, Jul 14, 2011 at 6:08 AM, JB <jb.1234abcd at gmail.com> 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 :-)
>

The only thing we do not strictly adhere to is the static sized
elements in the tree because we inline data in the tree if it is small
enough, which works out awesomely if you have small files because you
only do the read once.  Is this not in keeping with the original
algorithm?  Maybe.  Is it a problem?  More than likely not.  Can you
turn it off?  Yes.  Thanks,

Josef