| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
How The Backup Process Has Changed
How The Backup Process Has Changed
Posted Nov 29, 2007 16:36 UTC (Thu) by jimparis (subscriber, #38647)In reply to: How The Backup Process Has Changed by nix
Parent article: How The Backup Process Has Changed
Works fine for me (I don't see why LVM would care where the filesystem is mounted):
$ mount | head -1
/dev/raid1/root on / type ext3 (rw,errors=remount,ro)
$ sudo lvcreate --size 100m --snapshot --name snap /dev/raid1/root
Logical volume "snap" created
$ sudo lvdisplay /dev/raid1/snap | grep -i status
LV snapshot status active destination for /dev/raid1/root
LV Status available
(Log in to post comments)
How The Backup Process Has Changed
Posted Nov 29, 2007 17:17 UTC (Thu) by nix (subscriber, #2304) [Link]
It works but there's no guarantee that it won't deadlock. The problem is that LVM might need to read configuration state or executable pages (or write config backups) on the root filesystem, but the process of creating a snapshot includes a (brief) period when the origin volume is suspended, so reads and writes to it will block. The deadlock potential is, I hope, obvious.
How The Backup Process Has Changed
Posted Nov 29, 2007 19:31 UTC (Thu) by jimparis (subscriber, #38647) [Link]
OK, so copy static LVM binaries and configuration to a temporary ramdisk and run them from there. There's nothing special about "the root filesystem", there's just something special about "the filesystem that lvm lives on". And don't snapshot an active swap, that could get ugly :)
How The Backup Process Has Changed
Posted Nov 30, 2007 1:33 UTC (Fri) by nix (subscriber, #2304) [Link]
You might need to modify it to write its config backups and things somewhere else (preferably make it configurable at runtime). But yes, if you can avoid those problems then that might work, and thanks to tmpfs pretty much everyone has the moral equivalent of a ramdisk within easy reach. (Snapshotting an active swap partition is just barmy. Snapshotting a filesystem containing an active swapfile is careless and risky, but thankfully swapfiles tend to get used only for short-term oh-shit-we-need-another-X-Gb-of-swap-right-now stuff, at least in my experience. They're not something you habitually run with for ages.)
How The Backup Process Has Changed
Posted Nov 30, 2007 4:56 UTC (Fri) by njs (subscriber, #40338) [Link]
>thankfully swapfiles tend to get used only for short-term oh-shit-we-need-another-X-Gb-of-swap-right-now stuff, at least in my experience. They're not something you habitually run with for ages. Wandering *way* off topic, is there actually any reason we don't all use swap files these days, other than inertia? They certainly allow more flexible on-the-fly configuration of your swap needs, and I'm not aware of any disadvantages. Seems like a desktop distro optimizing for simplest-thing-that-works would be quite sane to just slap a single partition on the hard disk and then allocate a swapfile in it.
How The Backup Process Has Changed
Posted Nov 30, 2007 8:22 UTC (Fri) by nix (subscriber, #2304) [Link]
I'd go with inertia too. Splitting up your fs into more than one big lump still has advantages (putting your data somewhere else allows you to blow away the rest more easily: you can hive off filesystems as a whole onto remote storage slightly more easily: it keeps them safe from each other being corrupted to some degree; you can mount them readonly and so on) but IIRC the only advantage of swap partitions these days is that they're guaranteed to be contiguous.