> On Monday, 26 September 2016 12:11:56 UTC+10, [email protected] wrote: >> AppVM's are designed to toss changes, other than /home, /rw, /usr/local. >> It's a good thing; if one gets compromised, it's a temporary compromise. >> :) >> >> If you want permanent changes, update your template. >> >> But it sounds like you might want a "standalone VM": > > Hi JJ, I know it's meant to, but if I'm testing something, I want to > install pre-requisites for things, then it may have to restart, then I > want to take a snapshot, then perform the next step, then do another > snapshot, and revert if I need to.
Fair enough. That's something I also would find useful, and is why I'm switching to btrfs root soon. >> Also, using BTRFS as a root (or VM host) filesystem should allow you to >> snapshot/rollback the standalone VM to your heart's content (and clone >> it >> instantly). BTRFS is all about the copy-on-write. > > I'm not going to use that on an SSD, that creates way too many writes. As > far as I've read and know, correct me if I'm wrong, BTRFS is a journaling > file system, meaning it writes the changes that it's going to make to the > journal, and then writes the changes to the disk. This means it writes > everything twice. > On an SSD that isn't good, it decreases the life of the drive by over 50%. >From the BTRFS Faq: "There are some optimizations for SSD drives, and you can enable them by mounting with -o ssd. " "Mount -o ssd_spread is more strict about finding a large unused region of the disk for new allocations, which tends to fragment the free space more over time. Mount -o ssd_spread is often faster on the less expensive SSD devices. The default for autodetected SSD devices is mount -o ssd. " Doesn't sound too bad to me. Are SSD's really that prone to wearing out quickly? Ignoring spare files, if you consider that a reflink copy of, say, a 2G file (such as a VM .img file) takes almost no disk activity on BTRFS (just a metadata cloning due to the COW nature), while ext4 churns away reading/writing the full 2G of data, I'd say that BTRFS could *save* you a whole bunch of wear on your SSD. snapshotting and reverting under BTFS is near immediate, versus copying of multiple large files; seems like a no-brainer in favor of BTRFS. >From another page: "Btrfs is SSD-aware and exploits TRIM/Discard to allow the file system to report unused blocks to the storage device for reuse. On SSDs, Btrfs avoids unnecessary seek optimization and aggressively sends writes in clusters, even if they are from unrelated files. This results in larger write operations and faster write throughput, albeit at the expense of more seeks later." And: https://oss.oracle.com/pipermail/btrfs-devel/2008-February/000513.html And: https://www.linux.com/learn/weekend-project-get-started-btrfs which comments: "the system uses a copy-on-write strategy that writes changed data to disk first, then updates the references in the tree. This crash-proofs the filesystem, but without the overhead of maintaining a journal." (That article was six years ago, not sure if things have changed, but on a quick search I couldn't find any reference to BTRFS using journaling.) In fact, the wiki page on journaling filesystems: https://en.wikipedia.org/wiki/Journaling_file_system#Alternatives considers BTFS and COW-based filesystems as *alternatives* to journaling filesystems: "Full copy-on-write file systems (such as ZFS and Btrfs) avoid in-place changes to file data by writing out the data in newly allocated blocks, followed by updated metadata that would point to the new data and disown the old, followed by metadata pointing to that, and so on up to the superblock, or the root of the file system hierarchy. This has the same correctness-preserving properties as a journal, without the write-twice overhead." So your fears may be unfounded, and you might be missing out on a tech that provides exactly what you need. :) > This is why I use EXT2 Filesystem, even in the templates. (The templates > were originally EXT3/4 if memory serves, as an LVM. Flying without a journal (especially wrt metadata) is a bit bold in this day and age. :) > Well, I can't use Qubes 4.0, because you are FORCING it to REQUIRE > technology in the CPU that my Multi-CPU system doesn't have. That's a thorn in my side as well, but possibly the price of progress. JJ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/00003f782b239892ed875d93497ab3d1.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
