Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Apr 2017 21:11:35 +0200
From:      Miroslav Lachman <000.fbsd@quip.cz>
To:        Lee Brown <leeb@ratnaling.org>
Cc:        freebsd-geom@freebsd.org
Subject:   Re: glabel problem
Message-ID:  <58FBAAE7.9090508@quip.cz>
In-Reply-To: <CAFPNf5_gcbez7f5Y7drqdpUNUWQtuhe97jXPvxLcpbJOyjEV7Q@mail.gmail.com>
References:  <CAFPNf59g=Yo9oB16nf9pAE8wHKB_29aD0AZWsi%2BecKiC_4kEJQ@mail.gmail.com> <58FABB3A.6040704@quip.cz> <CAFPNf5_gcbez7f5Y7drqdpUNUWQtuhe97jXPvxLcpbJOyjEV7Q@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Lee Brown wrote on 2017/04/22 21:02:
>
>
> On Fri, Apr 21, 2017 at 7:08 PM, Miroslav Lachman <000.fbsd@quip.cz
> <mailto: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: <product 0x1234 vendor 0x048d> 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.

This is really strange. It seems faulty to me.

There are other things you can try:
1) try to create gpt partition of a small size - about 4GB a test geli 
on it. If it works then try to destroy this partition and create it 
again but big, about 10MB smaller than the device size (maybe there is 
some problem at the end of the device)

2) if it is not working with geli, try it with simple gpart GPT + newfs 
UFS or with ZFS. Once you have ZFS on it, you can put some files on it 
and then run zfs scrub - if device is faulty there should be some 
checksum errors in zpool status output.

Miroslav Lachman



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?58FBAAE7.9090508>