Date: Sat, 04 Jul 2015 00:09:51 +0800 From: Julian Elischer <julian@freebsd.org> To: Felipe Monteiro de Carvalho <felipemonteiro.carvalho@gmail.com> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: Uberblock location Message-ID: <5596B3CF.50703@freebsd.org> In-Reply-To: <CACyNnZOpawH=RLfP1cJqF58=dqiONNKoJ-DN4GLi9Jy=VnxZPA@mail.gmail.com> References: <CACyNnZMu=Y77uKNji0KP2atDGbT7Hv0RqGFaPDe1noMODv1iMw@mail.gmail.com> <557B0255.8060809@freebsd.org> <01184F08-1C6B-4282-9203-1BF98F07A05A@gmail.com> <557C282D.8060809@freebsd.org> <CACyNnZOpawH=RLfP1cJqF58=dqiONNKoJ-DN4GLi9Jy=VnxZPA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/2/15 6:02 PM, Felipe Monteiro de Carvalho wrote: > Hello, > > Ok, thanks a lot =) I am now working based on the FreeBSD source code, which? the kernel code or the bootblock code? I believe the bootblock version /usr/src/sys/boot/zfs from woudl be easier to start with. > 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. define "path".. in a way that is OS independent and meaningful when running in a bios environment (bootblocks). > > 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? i should be from the base of the partition containing the filesystem but I feel you are probably already doing this of you probably wouldn't have got this far. > > 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. you have gone as far as I can hep you.. I'll have to leave it to others. > > thanks,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5596B3CF.50703>