From owner-freebsd-fs@freebsd.org Fri Jul 3 16:10:02 2015 Return-Path: Delivered-To: freebsd-fs@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 810B6993FED for ; Fri, 3 Jul 2015 16:10:02 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5DAA82926 for ; Fri, 3 Jul 2015 16:10:01 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-224-92.lns20.per1.internode.on.net [121.45.224.92]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t63G9vKO009917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 3 Jul 2015 09:10:00 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5596B3CF.50703@freebsd.org> Date: Sat, 04 Jul 2015 00:09:51 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Felipe Monteiro de Carvalho CC: "freebsd-fs@freebsd.org" Subject: Re: Uberblock location References: <557B0255.8060809@freebsd.org> <01184F08-1C6B-4282-9203-1BF98F07A05A@gmail.com> <557C282D.8060809@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 16:10:02 -0000 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=DVA[0]= > DVA[1]= > DVA[2]= 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,