From owner-freebsd-geom@freebsd.org Sat Apr 22 19:02:56 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D74F9D4BCF5 for ; Sat, 22 Apr 2017 19:02:56 +0000 (UTC) (envelope-from leeb@ratnaling.org) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A4943B3 for ; Sat, 22 Apr 2017 19:02:56 +0000 (UTC) (envelope-from leeb@ratnaling.org) Received: by mail-vk0-x22a.google.com with SMTP id j127so23994657vkh.0 for ; Sat, 22 Apr 2017 12:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ratnaling-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BQYvEsLFje2HvCjnlHXJ0J8y+OBCD8l5D6RedY55i5Q=; b=2OOQ0xZGs+8Z9/tJ9i5nW9j1MBbJoP6/8gu/q3jKXIZv+6IMAhiXM4QIg1DVwhUDM7 Qj67K+1u0NXvwooowdqE/xPQPGnk1rCCO2uDTqPLKH5jqCusaBLr68l/4213TC7QFgCh IX6b9Ws49cEygCX0SrMHlfryFftQMvEtLJdL/6Smljdbz8uryCfGu7iJrhge4KWufr8n 2qKUUTjBRXBdtOAsbc+7dNSbhP+1KQIcUHuPk07RYvP37jYxUFlBgw5wB5qqloBzRIGe savcjqBU6zlxCYapLDscE9yniaeONumIFCUSuMmn4Nl3l0Gj1vnTQWPHeeVVmXDWAkeE vTxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BQYvEsLFje2HvCjnlHXJ0J8y+OBCD8l5D6RedY55i5Q=; b=g+D73ybWEmuJWstb8iElNawgD7ipCprKYTEvZ97mLr8SoCss8xWshVdDDpIt3Emn2l olTZr972S+pxd0mWC8JlvKqliXXkIbZapdfm7q2eUJk8s42aAdpu33aiy/2ztZuYHzQl lXRxuTT9ic7W1tIVWVJOsqkJm+VutDLeGwArA4tmJHkUOvaFeDufa6rcq14Ix81YcLlH lbuwNSHH5rrxQo5sxThI5AR8hey6KcYcmEc0TW2BaxMfa/hZLjQOsknMufrx82XKWX8i DNopu/hbnJtXAEImDWji3LEYFLBLYET74WIn/MjhVTncDDiU5BhZwPMzKgyUqVGZYUQI Z4iQ== X-Gm-Message-State: AN3rC/4Khkjm+7wXw7yqmvNGCdgfaFDLlL9muZhFoQXYVHROFEgYUA/r JW9ZOQBHfryztr/t0MlSQpUAe6jgRate X-Received: by 10.31.254.206 with SMTP id l197mr1267552vki.106.1492887775327; Sat, 22 Apr 2017 12:02:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.92.133 with HTTP; Sat, 22 Apr 2017 12:02:54 -0700 (PDT) In-Reply-To: <58FABB3A.6040704@quip.cz> References: <58FABB3A.6040704@quip.cz> From: Lee Brown Date: Sat, 22 Apr 2017 12:02:54 -0700 Message-ID: Subject: Re: glabel problem To: Miroslav Lachman <000.fbsd@quip.cz> Cc: freebsd-geom@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 19:02:56 -0000 On Fri, Apr 21, 2017 at 7:08 PM, Miroslav Lachman <000.fbsd@quip.cz> wrote: > Lee Brown wrote on 2017/04/22 03:26: > > [..] > > root@apron:~ # glabel label -v TEST da2 >> Metadata value stored on da2. >> Done. >> >> but >> root@apron:~ # glabel status da2 >> root@apron:~ # >> > > Did you tried to disconnect and reconnect after "glabel label". Sometimes > label is not visible until retaste of the device (true > /dev/da2) > Yes, I also tried a usb power-off/on cycle. > > I zero'd the first and last 1MB and re-tried the label operation, but all >> the sectors were still zero. >> I tried to use the usbdump utility and I can see *something* is written. >> >> gpart appears to do the right thing. >> newfs on the raw device appears to do the right thing. >> geli init complains it can't find the metadata. >> > > What about partitioning by gpart GPT with gpt partition label and then use > this label for geli instead of whole device? > geli complains in the same way, this is what I tried: root@apron:~ # dd if=/dev/zero of=/dev/da2 bs=1m count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 0.124755 secs (8405050 bytes/sec) root@apron:~ # dd if=/dev/zero of=/dev/da2 bs=1m oseek=1023999 dd: /dev/da2: end of device 2+0 records in 1+0 records out 1048576 bytes transferred in 0.039043 secs (26856688 bytes/sec) root@apron:~ # gpart create -s GPT da2 da2 created root@apron:~ # gpart add -t freebsd-ufs -a 4k -l test da2 da2p1 added root@apron:~ # glabel status Name Status Components gpt/test N/A da2p1 gptid/292e8661-2789-11e7-af35-001ec944dcb4 N/A da2p1 root@apron:~ # geli init -a HMAC/SHA256 -J /root/empty-password -K /root/geli.CANI-RL.key -s 4096 gpt/test geli: Unable to read metadata from gpt/test: Invalid argument. I tried with and without /dev prefix, with and without -s 4096 and even da2p1 which all gave me the same message. Other info: ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA) Now: root@apron:~ # gpart show da2 => 40 2097151920 da2 GPT (1.0T) 40 2097151912 1 freebsd-ufs (1.0T) 2097151952 8 - free - (4.0K) root@apron:~ # usbconfig -d 3.2 power_off root@apron:~ # usbconfig -d 3.2 power_on root@apron:~ # gpart show da2 => 40 2097151920 da2 GPT (1.0T) [CORRUPT] 40 2097151912 1 freebsd-ufs (1.0T) 2097151952 8 - free - (4.0K) root@apron:~ # dd if=/dev/da2 iseek=1023999 bs=1m | od -ha 0000000 0000 0000 0000 0000 0000 0000 0000 0000 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul * 4000000 1+0 records in 1+0 records out 1048576 bytes transferred in 0.049774 secs (21066694 bytes/sec) Could the device simply be faulty? It's quite slow, it'll take 28hrs to wipe it, so I filled the last 2mb and 1gb with random root@apron:~ # dd if=/dev/random of=/dev/da2 bs=1m oseek=1023998 dd: /dev/da2: end of device 3+0 records in 2+0 records out 2097152 bytes transferred in 0.111204 secs (18858633 bytes/sec) root@apron:~ # dd if=/dev/da2 iseek=1023998 bs=1m | od -ha 0000000 0000 0000 0000 0000 0000 0000 0000 0000 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul * 10000000 2+0 records in 2+0 records out 2097152 bytes transferred in 0.098105 secs (21376560 bytes/sec) root@apron:~ # dd if=/dev/random of=/dev/da2 bs=1m oseek=1023000 dd: /dev/da2: end of device 1001+0 records in 1000+0 records out 1048576000 bytes transferred in 51.457299 secs (20377595 bytes/sec) root@apron:~ # dd if=/dev/da2 iseek=1023000 bs=1m | od -ha 0000000 0000 0000 0000 0000 0000 0000 0000 0000 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul * 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 49.336478 secs (21253564 bytes/sec) 7640000000 It looks like it's just not writing beyond a certain point. Thanks for helping, this is really strange. > > Miroslav Lachman > > >