On 05/05/2015 04:48 PM, John Andersen wrote:
If BTRFS better balanced its trees
Good point but not the best way of putting it. Having written error correcting disk drivers I know that you can't spend much time in the kernel doing 'disk work'. A thread that balances the kernel as reading and writing proceeds is just that and will impact the user-perceived performance. Perhaps, since other B-tree based file systems seem to manage this, there is a fundamental design problem . There are external balance utilities just as there are FSCK programs for other file systems or de-fragmentation on MS-DOS file systems that need it (and certain archaic and rarely used early UNIX file systems). I'm not saying that BtrFS is "broken by design", but rather that a design decision is a limitation. I consider the fixed number of inodes allocated in the ext[234] file systems, something inherited from the 1970s origins of UNIX and only rectified in ReiserFS and XFS and similar, to be a similar design decision that I see as being a limitation. It doesn't affect day to day performance until the systems stops dead, though. The thing is that you can't really report 'design decision' as bugs, certain not this late in the game. I've tried complaining about fixed inodes in ext4 after running into inode exhaustion, and I was told to "over provision". Now isn't that what is being said about BtrFS? "Disks is cheap, make the file system larger, over 100G..." -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org