Date: Mon, 13 Jan 2014 19:57:43 -0600 From: Mark Felder <feld@FreeBSD.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: freebsd-geom@freebsd.org Subject: Re: "deep" gpart backup? Message-ID: <FC3C2BBA-9268-421D-8F28-B9E034A7010B@FreeBSD.org> In-Reply-To: <F0F3FBB0-348F-4F20-AE06-449A9A7B7E5E@xcllnt.net> References: <1023566295.20140105015301@serebryakov.spb.ru> <1389461267.16576.69479689.0A3D893A@webmail.messagingengine.com> <F0F3FBB0-348F-4F20-AE06-449A9A7B7E5E@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Jan 13, 2014, at 18:33, Marcel Moolenaar <marcel@xcllnt.net> wrote: > > On Jan 11, 2014, at 9:27 AM, Mark Felder <feld@FreeBSD.org> wrote: > >> On Sat, Jan 4, 2014, at 15:53, Lev Serebryakov wrote: >>> Hello, Freebsd-geom. >>> >>> Is here any way to make "deep" "gpart backup | gpart restore"? Now, when >>> I >>> have disk with MBR, with two slices, each of which has BSD label, I need >>> three calls of backup / restore commands with proper arguments. It looks >>> just stupid :) >>> >> >> If gpart can see and manipulate all of these elements it really should >> be able to backup and restore them all atomically. > > This statement is close to being ridiculous. Being able to > operate on all components is absolutely not a sufficient > condition for doing atomic operations across a multitude > of them. Atomicity is a very particular requirement. > You're right. Throwing out that word without thinking carefully was not smart. After considering the bit of knowledge I have about how geom operates it wouldn't be able to go a layer deeper without tasting first unless we somehow teach gpart how to prepare transactions and write the labels all at once, then re-taste the device. Probably more difficult than it's worth. I imagine a batch transaction that rolls back to the previous state could be achieved. Though we all know the attempt would taint any existing data, but if you're attempting this you should have already said your farewells to the data anyway :-) > Note also that gpart (in its most vague definition) cannot > actually manipulate on *all* elements at the same time. > Nested partitioning schemes are not seen by the gpart > invocation that works on the outer-most container. Only > when running gpart on a partition will it (= gpart) be > able to work on the nested partitions. As such, no single > gpart invocation sees all levels of nesting. > Aha, one step ahead of me :-) > gpart is an inherently low-level utility and what you want > is intended (i.e. by design) to be handled at an application > layer above gpart. > It's pretty low level, but it does seem to be missing some features I would expect in such a low level utility such as the ability to create partitions with custom IDs. Being limited to the handful defined in the gpart man page has caused me problems a few times. See: http://www.win.tue.nl/~aeb/partitions/partition_types-1.html which are almost all included in the Linux fdisk utility. Annnnd now something at the end of the gpart man page just caught my eye: AUTHORS Marcel Moolenaar <marcel@FreeBSD.org> I'll see my way out :-) [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS1JmXAAoJEJg7ZFAfE+JS8qgH/jmOqMNS/EZA+1QQDl8t9VLx o4bnAfzdA/bi36axHK5kWPsdHjNf3vJPyZnppCLWxm91J/o6QpN6JsvJ0L3rCIRn /JkX7vs/7mYGm6FgZdQLCjjlsZdU1bTr0jpsy61AMwp5IAnCzzpNhPqDxBUbFbSy ze4vheigwMUo4TyhBlqoGhBOYSfl3Vtr+cquuA0IP0fMPo7WO5GblrYtU3thPXi9 btpQTGEDwMHgLkfvP36yHb565uge3/vyFjGKZd6803QTcR38EkUoTyrUvQtM56At TldOmZSsrOy8w8QtgTroYJ3DkYe+XHNG2MO3+Rgl1NY+m8TFA/LRyGDETUStJhg= =qzxp -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FC3C2BBA-9268-421D-8F28-B9E034A7010B>