Date: Fri, 2 Oct 2015 18:26:45 -0400 From: "Chad J. Milios" <milios@ccsys.com> To: "William A. Mahaffey III" <wam@hiwaay.net> Cc: FreeBSD Questions !!!! <freebsd-questions@freebsd.org> Subject: Re: Geom question Message-ID: <560F04A5.1060102@ccsys.com> In-Reply-To: <alpine.BSF.2.20.1510021521390.7062@wonkity.com> References: <560EDE45.3040605@hiwaay.net> <3D81C7BC-1A31-4046-88B7-50F25EA3B952@ccsys.com> <560EEE5F.3080904@hiwaay.net> <alpine.BSF.2.20.1510021521390.7062@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/2/2015 5:25 PM, Warren Block wrote: > On Fri, 2 Oct 2015, William A. Mahaffey III wrote: > >> On 10/02/15 15:31, Chad J. Milios wrote: >>>> On Oct 2, 2015, at 3:41 PM, William A. Mahaffey III >>>> <wam@hiwaay.net> wrote: >>>> >>>> I am prepping to provision 2 boxen w/ FreeBSD 9.3R, preferably from >>>> a thumb drive. I would like to add a 'utils' directory w/ some >>>> scripts I wrote to automate the partitioning/slicing of the HDD's >>>> (2X on 1 box, 8X on the other), & also accumulate output from the >>>> install process in case questions arise. To that end, I am planning >>>> on partitioning/slicing a thumb drive, prepping it to be bootable >>>> following examples on the gpart man page, & copying verbatim stuff >>>> from the memstick.img for 9.3R that I downloaded a while back, as >>>> well as adding my utils directory. Reading up on gpart & geom >>>> raises 1 question: can I do all these preps on a disk image file I >>>> create w/ dd, or do i do them in place on the target memstick, then >>>> dd the results onto an on-disk image for safekeeping ? Put another >>>> way, can a disk image created by dd be a 'geom' for gpart ? TIA & >>>> have a good one. >>>> >>>> -- >>>> >>>> William A. Mahaffey III >>> In a way, yes. `mdconfig -f filename` will make your file accessible >>> as a virtual device. >>> >> >> Then to be accessed as /dev/md0 ? Any other clues/gotchas :-) ? >> Thanks & TIA & have a good one. > > GPT does not work well with that. If the target device is larger, the > backup GPT that is supposed to go at the very end of the disk ends up > someplace before that. If the target device is smaller, well, it > won't work at all. he's right. unless your md is exactly the correct total size, to the byte, the backup GPT header will be lost after copying to a different device. alas, it is a backup after all, unless/until the primary header suffers calamity, it'll cause you no grief. for the thorough/cautious `gpart recover da0` will fix it afterward, (assuming your data fits on the target and da0 is your usb stick). More problematic is that block sizes might mismatch. use `diskinfo -v $GEOM` to investigate, for each of your various top-level values for $GEOM. the "sectorsize" is the logical block size, which if mismatched can cause you overall configuration problems / total non-function. the "stripesize" is [if it can be detectected] your physical hardware blocksize which if mismatched will work but with abysmal performance. if stripesize is zero then nine times out of ten you can assume its the same as sectorsize. Then `gnop` is a geom layer utility for you that can fake different block sizes, so if you gnop your md0 to match your da0 you'll be able to make a proper image on md0 to transfer later to da0 > Also, avoid using dd on SSDs. dd's "conv=sparse,notrunc" mode of operation will alleviate this problem (the problem of beating it up with writes), though it'll leave sectors which are all zero on the source untouched on the target, which could be undesired. on an ssd you can TRIM the whole device first (logically zero it out without actually writing zeros) by using `camcontrol security $DEV -U user -s foo; camcontrol security $DEV -U user -e foo` replacing $DEV with ada0 (or your real target) to logically erase it. It should take no more than 5 minutes. (Despite the word "security", do not be fooled, this is a quick logical wipe and the old data can be recovered. It can do more with other options.) NOTE: while you research `man camcontrol` note theres a -u in the examples which should be -U, as I've just illustrated. This typo was fixed in HEAD and STABLE but may be in the RELEASE you're on. NOTE: cheapo usb sticks probably do not support TRIM. in general though, it's doubtful you have any real data blocks that are all zero and the un-zero'd blocks left on the target will likely all be ignored by virtue of the fact that the filesystem considers them free space. > In general, it's better to use higher-level things that understand the > metadata, like 'gpart backup'/'gpart restore' for the partitioning > information and dump/restore or 'zfs send' for the filesystems. > 'gpart restore' can correctly restore the partitioning scheme onto a > larger device because it understands what that data means. generally very good advice to follow. still, low-level hackery can be fun and educational :) Cheers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?560F04A5.1060102>