On Tuesday, 27 September 2016 14:23:45 UTC+10, [email protected] wrote: > > 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? Yes they do. I had 2 SSDs, both doing the same thing. One was EXT4, the other was EXT2. EXT4, after a check, had over 2 million errors on it. The EXT2 had 1 error. > 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.) Then perhaps the things I read back then were mistaken, or worded what they said the wrong way. > 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. :) Not really. > > 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. It's not the price of progress, it should be an OPTION in Qubes 4.0. That way, if you don't have it, you can still use Qubes 4. But if you have it, then you are (supposedly) more secure and still using Qubes 4. -- 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/a35b5dc2-dd08-4b2f-9fc9-69057d0e20f2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
