|
|
| Line 1: |
Line 1: |
| − | About this Adrien,
| |
| | | | |
| − | <pre>
| |
| − | # mkdir /live-root
| |
| − | # mount -o subvolid=0 /dev/sda4 /live-root
| |
| − | # rsync -aHA --exclude="/live-root" / /live-root
| |
| − | </pre>
| |
| − |
| |
| − | -- Indeed this is much better than my original idea I would also add -X to preserve all extended attributes.
| |
| − |
| |
| − | If you had install your Funtoo box inside a subvolume....
| |
| − |
| |
| − | For exemple :
| |
| − |
| |
| − | <pre>
| |
| − | Subvolid=0
| |
| − | ----> @root id=255 or any number
| |
| − | </pre>
| |
| − |
| |
| − | --- Please don't use @ in front of snapshots names, this is an horrible bad practice to ban. A VFS structure should remain transparent at anytime (this is the reason of why subvolumes are threaten like directories without fancy names by the kernel). What is true on a machine can be false on another, good luck for applications compatibility especially with complex structures implying nested directories/subvolumes.
| |
| − |
| |
| − | You would be able to use this instead :
| |
| − |
| |
| − | <pre>
| |
| − |
| |
| − | # mkdir /live-root
| |
| − | # mount -o subvolid=0 /dev/sda4 /live-root
| |
| − | # cd /live-root
| |
| − | # btrfs subvolume snapshot @root @live-root
| |
| − | </pre>
| |
| − |
| |
| − | I think that you should add something about installing a Funtoo inside a subvolume instead of installing it directly inside the subvolid=0
| |
| − |
| |
| − | --- Why not but I don't see clearly what would a major differences of installing a distribution in another subvolume rather than 0 would be.... I should dig to measure the consequences :-)
| |
| − |
| |
| − |
| |
| − | --- Installing a distribution in a subvolume give a great advantage. First, Now on my system, each time I emerge something, update something or depclean, I get automatics snapshot of them so I can do a very fast recovery after reboot (Or I can boot any prior version of my funtoo very easily. Also, The way I use subvolume give me the ability to copy/rsync everything *without* the mounted stuff if the from of my copy is the subvolume, "/var/disksetup/@root" on my system instead of /
| |
| − |
| |
| − | The other advantage is that all my subvolumes and snapshots are outside of my normal Funtoo VFS so safe from any human error because not mounted by default. I use the @ in the front of my subvolume (and not my mounting point pointing to them) to simply identify them as subvolume.. No incompatibility involved, the only tool who deal with them is the btrfs module and the btrfs-progs tools and the subvolume containing them is not mounted by default.
| |
| − |
| |
| − | In case if I break totaly my /, it's a lot faster to delete the @root subvolume and make a snapshot of the latest good snapshot as @root than... copying the whole snapshot to / so I get, instant recovery.
| |
| − |
| |
| − | [[User:destroyfx|destroyfx]]
| |
| − |
| |
| − | Also, you can even use a @home as a subvolume and with that, you can have 2 separate strategy to backup your stuff.
| |
| − |
| |
| − | Snapshot your @home every hour and @root every 12 hours.
| |
| − |
| |
| − |
| |
| − | There's a lot avantanges with subvolume.
| |
| − |
| |
| − | [[User:D2 racing|D2 racing]]
| |
| − |
| |
| − | My / (@root) is snapshoted at system modification with emerge and my /home (@home) is snapshoted at shutdown. This is a lot less hassle to manage for my automated recovery scripts... But maybe an hourly home backup is possible with some improvements.
| |
| − |
| |
| − | [[User:destroyfx|destroyfx]]
| |
| − |
| |
| − |
| |
| − | Again: using fancy names is not a good pratice in the general case. See my arguments before, you can scan a BTRFS volume to see what subvolumes are in it..... I can have subvolumes at several places in the VFS and some other others machines may not follow the same layout or not use subviolumes at all. Fancy names = pratice to *ban*.
| |
| − |
| |
| − | [[User:404_Error|404_Error]]
| |
| − |
| |
| − | Beside the fancy naming for snapshot, I don't understand why you insist to install your box directly inside the subvolid=0.
| |
| − |
| |
| − | For the record, install an Ubuntu 11.04 inside Virtualbox and install only one btrfs partition just to play with it.
| |
| − |
| |
| − | You will see that the Ubuntu installation will use the @ subvolume for the root partition and the @home is an another subvolume below the standard subvolid=0.
| |
| − |
| |
| − | I'm gonna ask the question on the BTRFS mailing-list and I hope that Chris will answer it :P
| |
| − |
| |
| − | For the rest, we need to wait and see :P
| |
| − | [[User:D2 racing|D2 racing]]
| |
| − |
| |
| − | -- At the time I did my funtoo installation I went through the simplest way and I didn't defined extra subvolumes to put the system in. Using whatever volume change nothing 0, 96 or 162 is nearly strictly the same at the end. The only advantage I see to not use subvol 0 is you can avoid the copy step when rolling back: simply set a default a working subvolume ID and drop the buggy one. My explanations are starting with that hypothesis. I will add an extra section to give some details about this point. Interesting detail to mention however, but I wouldn't borrow Chris Mason time for that kind of stuff.
| |
| − |
| |
| − | The VFS concept is to abstract the filesystem layout from its physical storage and violating this principle will bring you severe troubles (in the exact same kind of subject try to live with "All symlinks on the machine must start with a hash sign"). What this article says must be true on the general case and not for a snapshot of /home in a personal desktop. A real production machine can handle a complex nested structures of several filesystem including several nested BTRFS volumes. Ubuntu practices for sub naming convention SUCKS and are totally inadequate. This kind of stupid naming convention and breaking one the most fundamental VFS principals can lead to potential losses reaching several dozen of thousands of bucks on a real production system.
| |
