On 03/14/2016 09:48 PM, Carlos E. R. wrote:
On 2016-03-15 00:20, Anton Aylward wrote:
Please explain why one should keep the subvolumes?
Several reasons. Some are configured differently. No COW for databases, no snapshot revert on logs...
That explains how to configure subvolumes, not why you should keep them rather than repalcing them with a mounted file system. On 03/15/2016 03:22 AM, Vojtěch Zeisek wrote:
If I can say, subvolumes can be excluded from snapshots. It doesn't make sense to keep e.g. content of /tmp in snapshots. Disabling COW is good for performance of DB (and there is no need for snapshoting anyway). So subvolumes can save a lot of space and have positive impact to performance. Of course, if You make Your custom layout which fits Your needs, good for You...
Sorry, that rings of "proof by assertion". Yes, it doesn't make sense to keep /tmp and databases under snapshots. In fact it may make more sense to put them on separate file systems more suited to the kind of activity. There's the case, for example, that /tmp should be a tmpfs since its often used for intermediate files or scratchpad. Some applications, such as compiling, where the parse tree is built in a temporary file, I've seen accelerated by this means. You say that subvolumes can save space but you don't say how or compared to what, and you say that they can have a positive impact on performance, again compared to what. or why. Dollar for Dollar, there are many other ways to get better performance: * move to a SSD or a faster SSD * move to a faster motherbaord, DDR4, add more memory * get a faster GPU, more local memory * move to a faster, perhaps more core CPU -- Intel now has a 20 core chip! -- Consider overclocking * move to a Series 4 late model kernel that has better locking * use a lighter DM with less 'eye candy' Any/all of those will, I think, offer a better systemic performance than anything changing file systems back and forth will do. The reality is that without a fabulous graphic engine Darktable eats CPU doing rendering; I suspect the same holds for web page rendering. In other areas, the real performance bottleneck is not the disk, its the network. But ultimately the delays in almost everything exist between the chair and the keyboard. And those seem to degrade with time. Personally I think the ability of ReiserFS to stuff small files (of which there are many under /etc for example) into odd places "saves space" very well. But there are many applications where large extents, often reserved ahead of time, make more sense. For example, I do a great deal of photograph work using Darktable. The camera's RAW files are of the order of 24Megabytes. I don't care about block size rounding errors of a couple of K. Once a RAW file is created it is never modified. It is read and and 'edits' are recorded in a sidebar file (<name>.xmp) and one or more images are produced as a result of the edit (as a .tiff, .gif, .jpg or .png). In some ways a kind of "overlay" file system where RAW file is on a ROMFS would make more sense. But in reality its more sutied to XFS. The Photonix survey keep showing that BtrFS doesn't perform well in certain areas, and other contributors to this forum have made very clear the advantages of, for example XFS for specific use cases. http://www.phoronix.com/scan.php?page=article&item=linux-41-filesystem&num=1 I'd so hoped that BtrFS would be the successor to ReiserFS, building on ideas that it had proven such as the btree techniques, and breaking away from the extN model. But it seems the designers wanted to absorb volume management and RAID into one glorious UberDiskFuntionaryMaster. (Perhaps that would be better in German with a couple of umlauts?) This should have warned us. -- 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