Date: Fri, 2 Oct 2015 22:26:14 -0453.75 From: "William A. Mahaffey III" <wam@hiwaay.net> Cc: FreeBSD Questions !!!! <freebsd-questions@freebsd.org> Subject: Re: Geom question Message-ID: <560F498C.7090707@hiwaay.net> In-Reply-To: <560F04A5.1060102@ccsys.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> <560F04A5.1060102@ccsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/02/15 17:33, Chad J. Milios wrote:
> 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
I think I am good here, although I took no explicit steps to set sector
sizes (although I did carefully size md0 to (as exactly as possible) da0):
[root@kabini1, /etc, 5:42:20pm] 779 % diskinfo -v /dev/md0
/dev/md0
512 # sectorsize
3878682624 # mediasize in bytes (3.6G)
7575552 # mediasize in sectors
0 # stripesize
0 # stripeoffset
[root@kabini1, /etc, 10:21:06pm] 780 % diskinfo -v /dev/md1
/dev/md1
512 # sectorsize
717373440 # mediasize in bytes (684M)
1401120 # mediasize in sectors
0 # stripesize
0 # stripeoffset
[root@kabini1, /etc, 10:21:18pm] 781 % diskinfo -v /dev/da0
/dev/da0
512 # sectorsize
3878682624 # mediasize in bytes (3.6G)
7575552 # mediasize in sectors
0 # stripesize
0 # stripeoffset
471 # Cylinders according to firmware.
255 # Heads according to firmware.
63 # Sectors according to firmware.
C1005473D05C9225 # Disk ident.
[root@kabini1, /etc, 10:21:48pm] 782 %
da0 is the memstick, md0 is the stuff I am prepping, md1 is the image I
downloaded & will transfer to md0, along w/ some other stuff, to
eventually write to da0.
>
>> Also, avoid using dd on SSDs.
Not using a SSD here, but the warning is noted.
>
> 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.
>
--
William A. Mahaffey III
----------------------------------------------------------------------
"The M1 Garand is without doubt the finest implement of war
ever devised by man."
-- Gen. George S. Patton Jr.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?560F498C.7090707>