On 11/05/2014 06:39 AM, Carlos E. R. wrote:
Different feature set, there is some isolation between subvolumes. It is, I guess, like different partitions, but flexible, like in LVM. I haven't read it up, but I'd expect automatic resizing, or manual, but inside the current media container, which normally would be the entire hard disk.
That is what I've come to believe. The philosophy behind BtrFS seems to be to take the resource management we saw with LVM, where the logical extents, which may be on more than one spindle, are all managed as one pool. The difference between LVM and BtrFS here is that the pool == file system. For those of us who are used to using partitions, even LVM logical volumes, to divide the FS up into manageable chunks for various reasons[1], this is more scary than a 1980s slasher movie. There are advantages that cut in, or will eventually, with the COW and the optimizations that a B-tree system can perform at a global level. The ability to do RAID of some forms within the file system is attractive. What IS NOT is that I see no way where I can add another drive at a later date and make that part of the RAID as opposed to merely part of the FS. Maybe I'm wrong in that, but all the examples I've found for RAID with BtrFS involve it being set up at MKFS time. [1] see the link to /tmp security bug for example. see the use of "-x" in rync and "-xdev" in find to limit/speed things up see the use of partitions to limit how much space a runaway process can consume before its blocked -- 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