On Wed, Nov 17, 2010 at 4:46 PM, Anthony Roberts <btrfs-devel@xxxxxxxxxxxxxxxxxxxxx> wrote: > I think there's a few ancillary things like a working fsck needed > before it can even be recommended for widespread use, even to users > willing to risk any residual bugs. IIRC at this point the utilities > don't even aspire to provide basic recovery functionality (though > Chris has posted that fsck is coming). Yes, I think this is a rather big one, and one of the more directly addressed issues given the documentation at hand. I'm glad it looks like it is getting attention. > Beyond that, the management capabilities at this point don't look > ready for long term use in a production environment. By this I > mean adding/removing disks, reshaping arrays, etc. Without that I > might use BTRFS on top of LVM/RAID just like any other filesystem, > and there's features I'm looking forward to even if I that's all > I can do, but without robust management features there's certain > environments where it just doesn't make sense yet. I'd really like to see btrfs become able to simplify my life by removing LVM and/or RAID from the equation, that would be a very compelling reason to use it for me. Is there a place with a little more detail on what's missing to complete the storage-pool functionality? > There's one or two other things I'm keeping an eye on. That > limitation on the number of hardlinks you can have in a directory > is kinda irksome. I've heard this may require a format change, which if correct could be the cause of some reticence to use btrfs for very large file systems. > Also, dedup needs a way to verify/dedup safely > before people can start doing stuff like deduping live VM images. Hmm. Is that going to require a format change? Somehow it seems less likely... Cheers. -- fdr -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
