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
--Apple-Mail=_2568DAC3-8F87-4AB4-97AC-7995E3070FF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 13, 2014, at 18:33, Marcel Moolenaar <marcel@xcllnt.net> wrote: >=20 > On Jan 11, 2014, at 9:27 AM, Mark Felder <feld@FreeBSD.org> wrote: >=20 >> On Sat, Jan 4, 2014, at 15:53, Lev Serebryakov wrote: >>> Hello, Freebsd-geom. >>>=20 >>> 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 :) >>>=20 >>=20 >> If gpart can see and manipulate all of these elements it really = should >> be able to backup and restore them all atomically. >=20 > 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. >=20 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 (=3D gpart) be > able to work on the nested partitions. As such, no single > gpart invocation sees all levels of nesting. >=20 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. >=20 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 :-) --Apple-Mail=_2568DAC3-8F87-4AB4-97AC-7995E3070FF3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----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----- --Apple-Mail=_2568DAC3-8F87-4AB4-97AC-7995E3070FF3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FC3C2BBA-9268-421D-8F28-B9E034A7010B>