Originally posted by liam
View Post
As for Valerie, her article was linked specifically because she claimed a connection to ZFS (that implied an authoritative position) and she stated that she believed btrfs was better. I find it doubtful that it would have been linked if one of those two were not the case. It is therefore perfectly valid to question her connection to ZFS. Making some minor contributions to an early prototype that likely did not survive in what is now known as ZFS does not make one a ZFS developer. I can say with confidence that any claim that her opinions are that of a ZFS developer are false.
That being said, I cannot say that I am interested in doing the analysis of her article that you want. People who link it have already decided that they prefer btrfs and that is fine. Any attempt at analysis will predictably result in responses either nitpicking in the case that I do write one or stating that I cannot in the case that I do not. Given that this exercise is a complete waste of time, I will opt for the latter. In this case, that would not be entirely untrue. There exist people that are far better qualified to do this analysis than myself. Of course, this exercise would be a waste of time for them too.
I will leave you with one interesting fact. ZFS fills predictably such that writes will fail with ENOSPC only when df reports less space than the write (e.g. 0). btrfs can report ENOSPC without warning even when df reports substantial free space. A rebalance will fix things until the next ENOSPC, but that is not well suited for production environments, where space requirements need to be predictable. Few who read Valerie's claims of efficiency in comparison to ZFS would expect btrfs to have this problem when ZFS is free of it. Even fewer would expect btrfs to have pioneered it.
Leave a comment: