Re: [gentoo-user] Organising btrfs subvolumes
On Fri, 23 May 2014 00:34:25 +0200, Stefan G. Weichinger wrote: I'm working on this btrfs malarkey and have a question about best practice. It is recommended to leave the root volume empty and create a subvolume for the root filesystem which is set with btrfs subvolume set-default, which I have done. Alternative: mount the subvol via option subvolid etc in fstab if you plan to mount different snapshots, for example. I went with set-default for the root subvolume, if I need the root volume I can mount it with subvolid=0. What is the recommended way to create subvolumes that are mounted further down the filesystem? Let's say I was usr and var on their own subvolumes. Do I create them in the btrfs root, which means they have to be mounted from /etc/fstab - or do I create hem below the subvolume called root? I saw more examples mounting every dir via a separate line in fstab (which also adds the choice to mount them with different options, think compression etc). That makes sense, and will be useful should we ever get encryption. My understanding is: * create and use subvols for entities you want to be able to snapshot and rollback individually. * create and use subvols for entities you want to apply special options to: compression, (no)COW, quota ... I would mount each subvol via extra line and create them in parallel ... That's what i ended up doing, thanks. I did have an issue with systemd failing to mount them because the correct symlinks hadn't been created when I run cryptsetup in the initramfs, because it doesn't use udev, but that was fairly easy to fix. That raises another question. Assuming I've done it wrong (well, my wife always does) is there an equivalent to the zfs rename command to move or rename a subvolume? As far as I understand you are allowed to mount the root volume (or academic: any subvol in a higher level) and use plain mv to rename the subvols as if you renamed sub-dirs. rust me to overlook the easy way of doing things, I was looking for an equivalent to zfs rename and never considered mv. So far, btrfs looks good on my laptop - time to think about putting it on my desktop. -- Neil Bothwick Ifyoucanreadthis,youspendtoomuchtimefiguringouttaglines. signature.asc Description: PGP signature
Re: [gentoo-user] Organising btrfs subvolumes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 27.05.2014 09:59, schrieb Neil Bothwick: Alternative: mount the subvol via option subvolid etc in fstab if you plan to mount different snapshots, for example. I went with set-default for the root subvolume, if I need the root volume I can mount it with subvolid=0. Yes, just a question of preference. I prefer to specify a subvolid ... this won't lead to side-effects if I ever might set-default to something else. But it's easier to use the defaul subvolid if you refer to that subvol via grub2 or dracut etc ... Something I still learn about ... As far as I understand you are allowed to mount the root volume (or academic: any subvol in a higher level) and use plain mv to rename the subvols as if you renamed sub-dirs. rust me to overlook the easy way of doing things, I was looking for an equivalent to zfs rename and never considered mv. It feels somehow wrong to only mv them, right? ;-) So far, btrfs looks good on my laptop - time to think about putting it on my desktop. Yeah, good luck with that. I am quite happy with btrfs so far ... no problems or disadvantages so far. And the hourly snapshots of / and /home on my desktop are really nice to have ;-) Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJThG+2AAoJEClcuD1V0PzmqXsP/jkK/dYlatk90CbXwc/H71Y3 VPuT8y0P8zrsrMdwziG8BzvL5ivL6xTEMmxXmi5frWHgC9751UmqZVlCI6I2+dYQ ffjZYLqf3Q6FXKIcZ09Sbuxg+FsuEqw2LLrWXmSgWDrf5YQ0GAOjZupL4ii8dtUt heBGUXWHMdR6JQOgqAl5+g+f1HlDEnVDf49L5AbKE5wkeCirNPZzx4I54k8SNykG N7TLUe+AGzCsDAOL8BWpLrAyCyuWkMc01sfZN0sp36wzt4IsMxQYQFxq1ndmtEWf LneGfQzAalXY26YnKvpAczyeTLcwdWw5TK0Yd8ftvnJz8Q++h4KQOAzqyaVBlMKi oYis1WugSeKOG5JebOd5vNYQ/Po4NaGmidLkvTARFf7lSyLdND+dOQRkCBuzN2Q0 i/G+C5OFVSI8Mp+7qmHfWIOaKdi36Zi8luKV937gJD2+y/oS0tJiOWICSo4bqAIh 5/yaSWg3rUfxQ0aYzQG8U055CpcvhfZntqt0HKn4/NOuw42T4/r/nFplIhB1/Qgz qIGmkvCupUNRrpSfY+CjbNKMeO4LDpNpruU2qThwYBPMWQ/m3Iq1zEAkR4vYNetA 3oFdqEZmJsOI/e/uTBfpSTGsk9bP9y9rEIEjzmjTXEN8OjwfpMoB/Dn9C0J9uK25 MdA7u6Xx0JfbJ1qOXNQl =b71z -END PGP SIGNATURE-
Re: [gentoo-user] Organising btrfs subvolumes
On Tuesday 27 May 2014 11:57:58 Stefan G. Weichinger wrote: Am 27.05.2014 09:59, schrieb Neil Bothwick: Alternative: mount the subvol via option subvolid etc in fstab if you plan to mount different snapshots, for example. I went with set-default for the root subvolume, if I need the root volume I can mount it with subvolid=0. Yes, just a question of preference. I prefer to specify a subvolid ... this won't lead to side-effects if I ever might set-default to something else. But it's easier to use the defaul subvolid if you refer to that subvol via grub2 or dracut etc ... Something I still learn about ... As far as I understand you are allowed to mount the root volume (or academic: any subvol in a higher level) and use plain mv to rename the subvols as if you renamed sub-dirs. rust me to overlook the easy way of doing things, I was looking for an equivalent to zfs rename and never considered mv. It feels somehow wrong to only mv them, right? ;-) So far, btrfs looks good on my laptop - time to think about putting it on my desktop. Yeah, good luck with that. I am quite happy with btrfs so far ... no problems or disadvantages so far. And the hourly snapshots of / and /home on my desktop are really nice to have ;-) Stefan I recall that zfs needed a lot of RAM = 8M, is it the same with BTRFS? Also how big is each snapshot of / and why are these necessary on an hourly basiszfs ? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Organising btrfs subvolumes
On Tue, May 27, 2014 at 7:25 AM, Mick michaelkintz...@gmail.com wrote: Also how big is each snapshot of / and why are these necessary on an hourly basiszfs ? Btrfs is COW, so snapshots only consume space as files change. If you have a read-only filesystem and snapshot it hourly the only space consumed by a snapshot will be a few metadata records. Snapshotting hourly would mostly be a convenience - in theory it should get you time-machine-like functionality just like hourly backups would, but with far less overhead and space use. In practice I stopped doing this, as btrfs can misbehave when you start getting a lot of snapshots accumulated (we're talking thousands). It probably doesn't help that I have VM images snapshotted (though these images have fairly low write volumes - the most active one does most of its writing to an nfs volume so only OS updates, logs, etc change the VM). When snapper would go to cleanup snapshots I'd get panics. I ended up having to write a script that deleted one snapshot every 30min over the course of days to clean up from that. Now I only manually snapshot periodically and I haven't had a problem with it. I suspect that as with many things btrfs-related that it will be worked out in time, though snapshots will always cause fragmentation as long as the filesystem does partial diffs. Rich
Re: [gentoo-user] Organising btrfs subvolumes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 27.05.2014 13:25, schrieb Mick: I recall that zfs needed a lot of RAM = 8M, is it the same with BTRFS? I assume you mean 8GB ? As far as I know and researched: no, btrfs is less memory hungry and was designed to even work fine on small devices like phones or so. It depends if you use features like deduplication which is very ressource-intensive ... Also how big is each snapshot of / and why are these necessary on an hourly basiszfs ? Snapshots don't have any size initially. With filesystems like btrfs and zfs a snapshot is more of a pointer to a specific status of the whole fs-tree in time and in consequence also happens instantly. The size of the snapshot ... oh, Rich already replied as well :-) Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJThHlUAAoJEClcuD1V0PzmApcP/RCBeASWCqKOxDhtyJ7Pj+c3 LgDObKZ23svRCU2qiwF04e1enJTUF+FcaL/KyB4690x1EATo+0ciYOajzgIRng16 24bGB/ZCRhE4uZ99aVLymAslhBXUyILcZ+AqaJCM2XL72Ttp7gqB/PW0bJWOgQ0Y wC4FWtzDJN6vm2VfC3gDMhdUaoysWuCEQqhppJe5RpSbOP3kk9PzXiFLPpJkKs2V xglvGDy5SCu79APTqUrDRZtHCQBpLTkMDBQr9ytdtVLPDDx6WyG0BZ351tp2fzMp CMUy4T1z417l+TgDMZ2iYBh1+Ctnqkr+SfLdlkkF+0AJfpFUpNjztDHyhV8Muzan AQdEDW1ccXc/cSR62gbf8+Y+Aj2QTBPImXtHNHQHPRiszVgJM7E5ufnxrUm+1qT9 aWM+SSLbDjtvmRBSOExNawonprMT44Vhqc4j0UfLhbLsLZfVbUghfczqOr5pDD6l 32dIkXRtT/zkR/tDpWX5n6ZotIlnAuVh7xIe8zID3KTLXdcuM2sP3UDFUGd4FqPU 5ovfAIhi133BHpdz7FHmTbR9if7iGeF+mWFfCt/cWYQY9vw3yLmUaJg3pxP0gKvC C3SXt8V30ubWKglrCXd0a3eqm0fbonFaACdB3eyeQgi5S4FBYHIATW8XDGP+/VSG t81Av1TKapRTzHgQF35U =lMUl -END PGP SIGNATURE-
Re: [gentoo-user] Organising btrfs subvolumes
On Tue, 27 May 2014 12:57:58 +0200, Stefan G. Weichinger wrote: Trust me to overlook the easy way of doing things, I was looking for an equivalent to zfs rename and never considered mv. It feels somehow wrong to only mv them, right? ;-) It's just too easy, there must be a catch :) So far, btrfs looks good on my laptop - time to think about putting it on my desktop. Yeah, good luck with that. I am quite happy with btrfs so far ... no problems or disadvantages so far. And the hourly snapshots of / and /home on my desktop are really nice to have ;-) I have zfs-snapshot making snapshots at 15 minute, hourly, daily, monthly and weekly intervals - and it cleans up after itself. There isn't anything quite like that for btrfs, so I'm knocking up a python script to take care of it. I want automated snapshots before I risk it on my desktop. -- Neil Bothwick Do you steal taglines too? signature.asc Description: PGP signature
Re: [gentoo-user] Organising btrfs subvolumes
On Tue, 27 May 2014 12:25:48 +0100, Mick wrote: I recall that zfs needed a lot of RAM = 8M, is it the same with BTRFS? If you means 8GB, it doesn't. I am/was using it on several systems with 4GB. you can control the amount of memory used for its caches. -- Neil Bothwick If you consult enough experts, you can confirm any opinion. signature.asc Description: PGP signature
Re: [gentoo-user] Organising btrfs subvolumes
On Tue, 27 May 2014 07:38:01 -0400, Rich Freeman wrote: Snapshotting hourly would mostly be a convenience - in theory it should get you time-machine-like functionality just like hourly backups would, but with far less overhead and space use. In practice I stopped doing this, as btrfs can misbehave when you start getting a lot of snapshots accumulated (we're talking thousands). I've read that too. I'm looking at doing a kind of round robin thing where a script makes a snapshot and then deletes the oldest one. -- Neil Bothwick ... I'm simply not a nice girl, she whispered tartly. signature.asc Description: PGP signature
Re: [gentoo-user] Organising btrfs subvolumes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 27.05.2014 13:49, schrieb Neil Bothwick: I have zfs-snapshot making snapshots at 15 minute, hourly, daily, monthly and weekly intervals - and it cleans up after itself. There isn't anything quite like that for btrfs, so I'm knocking up a python script to take care of it. I want automated snapshots before I risk it on my desktop. Oh, I have something like that. Copied here: http://marc.merlins.org/perso/btrfs/post_2014-03-21_Btrfs-Tips_-How-To-Setup-Netapp-Style-Snapshots.html I wrapped some helper stuff around it to make it work with 2 btrfs-pools and systemd (and a timer there to even avoid running cron). Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJThHx8AAoJEClcuD1V0Pzmnj4QAKcZIghxoDgVVbI7a1rIltxl fAPdRvY5g5We0v/VJ7RL9vJe1tJ9F2UnzDBC/rEPw8XSPR1zJxhrFyCrdmumMYY+ qac4XSRCSS92subHwnYfjWxigqLk7DT86ATTEIo841YmQTdrfRyzmxwVHwvoONOB APasAal8Re7PFd01UAGpCurAzA20lMs1CFlqK/sBcWwM9RGsRzPwUZsfLiKcmdmX Ta4YUO/RtOv/RWntyHYJZ0FgcxmNo+HLCE6821mOxg+CyDp9Vag/6HWlXbZW1MRM /CVHQ8kim+azcEuX0NU7WDIfotPrXtb8PGZt+2QJtJm12CJQficQrUOZpmgoi3yM 7n1ux1VkM7avnXkoJ90/T5eWznq8d/NqTaESUHLnOPueE7JciR5gc3kNEgcriD7Y qHM9ZDG4vzRScUcLowZydsK32FHZdFRHUpNkwE2Admffz7+Sv3TfZqog2rs0WVoM zVBoKr3DY1LQo7NvHQJT2sfMKzBJq0kFoBY7yvwnJkzf2htlnhT2jOFg+XzTC0Hr IEHzEu/yzfmwKp490U3+jAfCxEnaGNIW1YZ+lA+kzS+6+9DWR+XYuaV/EV/wvE9s J2oPqzwzpcaBLxLY+Mq8cz/sXOASf6ICYYy1w+GfH82e/DYzfn/j+FTIxmjK6KVe t6/tx2rwGeNL1AhKaSmY =QHMO -END PGP SIGNATURE-
Re: [gentoo-user] Organising btrfs subvolumes
On Tue, May 27, 2014 at 7:49 AM, Neil Bothwick n...@digimed.co.uk wrote: I have zfs-snapshot making snapshots at 15 minute, hourly, daily, monthly and weekly intervals - and it cleans up after itself. There isn't anything quite like that for btrfs, so I'm knocking up a python script to take care of it. I want automated snapshots before I risk it on my desktop. There is snapper, which is even in the tree now. It isn't 100% flexible but supports any number of hourly, daily, monthly, and yearly snapshots, with retention policies for each. My problem was that the snapshots were created hourly, but cleaned up daily, which meant 24 deleted in parallel at a time. In general I've tended to notice that btrfs tends to suffer from hurry-up-and-wait issues. It will happily accept a ton of writes (even from an ioniced process) which I imagine go into the log, and then the whole filesystem will come to a halt at the next checkpoint (every 30s by default). It makes ionice just about useless, since the filesystem accepts more data than it can handle, and then blocks even realtime-priority processes while it is catching up. I suspect that it was having a related issue with snapshot removals. 24 huge snapshot removal commands complete in almost zero time, and then in 30s the debt comes due. In order to be a bit more ionice-friendly the filesystem needs to figure out what it can sustain and throttle writes to a reasonable rate. I'm fine with having some allowance for bursting, but having all disk access block for 10-20 seconds isn't acceptable. Oh, and chromium just loves its disk cache - it will happily wait for 20 seconds to read a cache entry that it could have downloaded online in less than a second. Rich
Re: [gentoo-user] Organising btrfs subvolumes
Am 27.05.2014 14:12, schrieb Rich Freeman: There is snapper, which is even in the tree now. It isn't 100% flexible but supports any number of hourly, daily, monthly, and yearly snapshots, with retention policies for each. no systemd-unitfiles yet, correct? I merged it and took a quick look, as far as I understand it needs a service running ... I will check back later this evening and see how to get that working here. Stefan
Re: [gentoo-user] Organising btrfs subvolumes
On Tue, May 27, 2014 at 8:58 AM, Stefan G. Weichinger li...@xunil.at wrote: Am 27.05.2014 14:12, schrieb Rich Freeman: There is snapper, which is even in the tree now. It isn't 100% flexible but supports any number of hourly, daily, monthly, and yearly snapshots, with retention policies for each. no systemd-unitfiles yet, correct? I merged it and took a quick look, as far as I understand it needs a service running ... I will check back later this evening and see how to get that working here. It uses crontab and portage hooks (though I don't know if the package in portage installs hooks, and if you don't want hundreds of snapshots you probably don't want them anyway). Rich
Re: [gentoo-user] Organising btrfs subvolumes
On Tuesday, May 27, 2014 12:57:58 PM Stefan G. Weichinger wrote: Am 27.05.2014 09:59, schrieb Neil Bothwick: So far, btrfs looks good on my laptop - time to think about putting it on my desktop. Yeah, good luck with that. I am quite happy with btrfs so far ... no problems or disadvantages so far. And the hourly snapshots of / and /home on my desktop are really nice to have ;-) Hourly snapshots are nice, but I wonder how much need there is if the filesystem itself doesn't change very much. I am still happily using LVM with snapshots. Those are instantaneous as well and I can then backup the snapshot, which on my server takes between 2 hours (incremental) and 3 weeks (full) When a snapshot is backed up, it is removed. The process to create the snapshots runs daily, but I could also configure it to run more often. This means that when I start a daily backup, the incrementals are piling up as snapshots. With 15 different filesystems to backup, I didn't experience any issue with this. I wonder how btrfs would deal with a situation like this? -- Joost
Re: [gentoo-user] Organising btrfs subvolumes
On Tue, May 27, 2014 at 10:09 AM, J. Roeleveld jo...@antarean.org wrote: I am still happily using LVM with snapshots. Those are instantaneous as well and I can then backup the snapshot, which on my server takes between 2 hours (incremental) and 3 weeks (full) When a snapshot is backed up, it is removed. The process to create the snapshots runs daily, but I could also configure it to run more often. This means that when I start a daily backup, the incrementals are piling up as snapshots. With 15 different filesystems to backup, I didn't experience any issue with this. I wonder how btrfs would deal with a situation like this? btrfs wouldn't have any issues with this at all. You'd have an advantage in that you wouldn't have to unmount the filesystem to cleanly create the snapshot (which you have to do with lvm). If you're concerned about application-level consistency you still need to get applications to flush their writes/checkpoint/etc (which don't have to be on disk, but they do have to be sent to the kernel). If you want to get really crazy you could make use of btrfs send as well - which is a filesystem-level function which tracks the actual changes between snapshots. Think of it like librsync with full file comparisons (a very expensive mode that few use in practice) but it doesn't need to actually read the files or have access to the destination files to find the differences. Doing this does require keeping around a snapshot until all backups incrementally created against it are done (if there are going to be any). But, you can always just create a snapshot, write it to backup with your favorite tool (it is just a directory tree), and then remove it as soon as you're done with it. Creating a snapshot is atomic at the filesystem level, though again if you want application level consistency you need to deal with that until somebody comes up with a transactional way to store files on Linux that is more elegant that fsyncing on every write. Rich
[gentoo-user] Organising btrfs subvolumes
I'm working on this btrfs malarkey and have a question about best practice. It is recommended to leave the root volume empty and create a subvolume for the root filesystem which is set with btrfs subvolume set-default, which I have done. What is the recommended way to create subvolumes that are mounted further down the filesystem? Let's say I was usr and var on their own subvolumes. Do I create them in the btrfs root, which means they have to be mounted from /etc/fstab - or do I create hem below the subvolume called root? That raises another question. Assuming I've done it wrong (well, my wife always does) is there an equivalent to the zfs rename command to move or rename a subvolume? -- Neil Bothwick Unsupported service (adj): Broken (see Demon) signature.asc Description: PGP signature
Re: [gentoo-user] Organising btrfs subvolumes
Am 22.05.2014 18:12, schrieb Neil Bothwick: I'm working on this btrfs malarkey and have a question about best practice. It is recommended to leave the root volume empty and create a subvolume for the root filesystem which is set with btrfs subvolume set-default, which I have done. Alternative: mount the subvol via option subvolid etc in fstab if you plan to mount different snapshots, for example. What is the recommended way to create subvolumes that are mounted further down the filesystem? Let's say I was usr and var on their own subvolumes. Do I create them in the btrfs root, which means they have to be mounted from /etc/fstab - or do I create hem below the subvolume called root? I saw more examples mounting every dir via a separate line in fstab (which also adds the choice to mount them with different options, think compression etc). My understanding is: * create and use subvols for entities you want to be able to snapshot and rollback individually. * create and use subvols for entities you want to apply special options to: compression, (no)COW, quota ... I would mount each subvol via extra line and create them in parallel ... That raises another question. Assuming I've done it wrong (well, my wife always does) is there an equivalent to the zfs rename command to move or rename a subvolume? As far as I understand you are allowed to mount the root volume (or academic: any subvol in a higher level) and use plain mv to rename the subvols as if you renamed sub-dirs. Stefan
