Date: Thu, 2 Jul 2015 12:02:39 +0200 From: Felipe Monteiro de Carvalho <felipemonteiro.carvalho@gmail.com> To: Julian Elischer <julian@freebsd.org> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: Uberblock location Message-ID: <CACyNnZOpawH=RLfP1cJqF58=dqiONNKoJ-DN4GLi9Jy=VnxZPA@mail.gmail.com> In-Reply-To: <557C282D.8060809@freebsd.org> References: <CACyNnZMu=Y77uKNji0KP2atDGbT7Hv0RqGFaPDe1noMODv1iMw@mail.gmail.com> <557B0255.8060809@freebsd.org> <01184F08-1C6B-4282-9203-1BF98F07A05A@gmail.com> <557C282D.8060809@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Ok, thanks a lot =) I am now working based on the FreeBSD source code, and I made a lot of progress at adapting it to my needs. My use is very different, so its not a simple "use as is", so I'm trying to understand what goes on in every step to adapt it, and I have arrived at a point where I got lost. Ok, so far I have the following working: Part 1> Read the disk label: based on function vdev_probe, reads from the disk the type vdev_phys_t This issues the following data: [0] DATA_TYPE_UINT64 name="version" val=5000 [1] DATA_TYPE_STRING name="name" val="zfs_felipe_2" [2] DATA_TYPE_UINT64 name="state" val=1 [3] DATA_TYPE_UINT64 name="txg" val=164 [4] DATA_TYPE_UINT64 name="pool_guid" val=8752563210577670337 [5] DATA_TYPE_UINT64 name="errata" val=0 [6] DATA_TYPE_UINT64 name="hostid" val=8323329 [7] DATA_TYPE_STRING name="hostname" val="felipe-VirtualBox" [8] DATA_TYPE_UINT64 name="top_guid" val=2451523895343473151 [9] DATA_TYPE_UINT64 name="guid" val=2451523895343473151 [10] DATA_TYPE_UINT64 name="vdev_children" val=1 [11] DATA_TYPE_NVLIST name="vdev_tree" >=[0] data_type_string 'name'="type" val="disk" >=[1] data_type_uint64 'name'="id" val=0 >=[2] data_type_uint64 'name'="guid" val=2,45152389534347E+018 >=[3] data_type_string 'name'="path" val="/dev/loop7" >=[4] data_type_uint64 'name'="whole_disk" val=0 >=[5] data_type_uint64 'name'="metaslab_array" val=34 >=[6] data_type_uint64 'name'="metaslab_shift" val=21 >=[7] data_type_uint64 'name'="ashift" val=9 >=[8] data_type_uint64 'name'="asize" val=257425408 >=[9] data_type_uint64 'name'="is_log" val=0 >=[10] data_type_uint64 'name'="create_txg" val=4 [12] DATA_TYPE_NVLIST name="features_for_read" >=[0] data_type_boolean 'name'="com.delphix:hole_birth" >=[1] data_type_boolean 'name'="com.delphix:embedded_data" This part is OK, although I was upset that in a pool with 2 disks, there is no info in each disk about the other one, except that vdev_children=2 =( It would have been great if there was the path to the second disk, but anyway, this is no huge problem. Part 2> Read the uberblocks and figure out which is the most current one. I select the uberblock with the largest ub_timestamp as the best one, and then I try to read the data pointed to by the uberblock.ub_rootbp of type blkptr_t The best uberblock has the following ub_rootbp: [0] VolumePos=$28000 DiskPos=$28000 IsVolumePosValid=1 IsSBValid=1 OriginNr=4 SB.ub_version=5000 SB.ub_timestamp=555CA4DF SB.ub_software_version=5000 BlockPtr=<bp>DVA[0]=<vdev=0:off=325D400:asize=200> DVA[1]=<vdev=0:off=621A000:asize=200> DVA[2]=<vdev=0:off=920F400:asize=200> LEVEL=0 TYPE=B LSIZE=800 PSIZE=200 COMP=F BIRTH=A0 PHYS_BIRTH=A0 read using the functions such as BP_GET_COMPRESS, etc. And this part is where I am stuck, because: 1> The offset 0x325D400 counting from disk image start is filled with CC CC CC CC .... it doesn't look like at all that it is something valid. Maybe the offset should not be read from disk image start, but instead counting from somewhere else? 2> comp=F wow, so even basic blocks use compression? Or my reading of the data somehow wrong? It will be a lot of work to get decompression working. any ideas? Attached is the "best" uberblock, with block pointer data with blue background. thanks, -- Felipe Monteiro de Carvalho
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACyNnZOpawH=RLfP1cJqF58=dqiONNKoJ-DN4GLi9Jy=VnxZPA>