From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <20130628173824.GA225@polynum.com> <1b43a3f01fbc1bc34fbca3e3fd19813a@coraid.com> Date: Fri, 28 Jun 2013 22:06:11 +0200 Message-ID: From: Gorka Guardiola To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e01538d54057d1a04e03c6914 Subject: Re: [9fans] plan9 iso image Topicbox-Message-UUID: 68bccc96-ead8-11e9-9d60-3106f5b1d025 --089e01538d54057d1a04e03c6914 Content-Type: text/plain; charset=ISO-8859-1 So... looking at the standard, the problem may be that the volume size is in bytes instead of in blocks? When I xd a plan 9 image (bytes are represented in little and big endian): 0008000 01434430 30310100 504c414e 20392042 0008010 4f4f5420 49534f39 36363020 20202020 0008020 20202020 20202020 504c414e 2039202d 0008030 204d4159 20372032 30313220 32333a32 0008040 33202020 20202020 00000000 00000000 0008050 00305600 00563000 00000000 00000000 ^^^^^^ ^^^^^^^ volume size in bytes (should this be in logical blocks?) 0008060 00000000 00000000 00000000 00000000 0008070 00000000 00000000 01000001 01000001 0008080 00080800 0a000000 0000000a c60a0000 ^^^^^ ^^^^ Block size, 2K 0008090 00000000 00000ac7 00000000 2200c20a 00080a0 00000000 0ac20010 00000000 10007005 00080b0 07151737 00020000 01000001 01003956 The size of the iso given by ls is 5656576, 0x00565000 which is close enough to 0x563000 in bytes. I xd a 90M linux iso I have and got: 0008000 01434430 30310100 4c494e55 58202020 0008010 20202020 20202020 20202020 20202020 0008020 20202020 20202020 4344524f 4d202020 0008030 20202020 20202020 20202020 20202020 0008040 20202020 20202020 00000000 00000000 0008050 fdb30000 0000b3fd 00000000 00000000 ^^^^^^^^^^^^^^^^^ 90M/2K 0008060 00000000 00000000 00000000 00000000 0008070 00000000 00000000 01000001 01000001 0008080 00080800 0a000000 0000000a 14000000 ^^^^^^^^^ 2K block size 0008090 00000000 00000016 00000000 22001800 00080a0 00000000 00180008 00000000 08006b05 00080b0 1808100a 20020000 01000001 01002020 So the size should be in Blocks and it is in bytes, this is why it is wrong. I don't understand why k3b reports double the size because it is much more. Unless I am not seeing something... G. On Fri, Jun 28, 2013 at 8:57 PM, Gorka Guardiola wrote: > http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf > > page 19: > > > Volume Space Size (BP 81 to 88) > This field shall specify as a 32-bit number the number of Logical Blocks > in which the Volume Space of the > volume is recorded. > This field shall be recorded according to 7.3.3. > > > > > -- - curiosity sKilled the cat --089e01538d54057d1a04e03c6914 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So... looking at the standard, the problem may = be that
the volume size is in bytes instead of in blocks?

When I xd a plan 9 image (bytes are rep= resented in little and
big endian):

0008000 = =A001434430 30310100 504c414e 20392042
0008010 =A04f4f5420 49534f= 39 36363020 20202020
0008020 =A020202020 20202020 504c414e 203920= 2d
0008030 =A0204d4159 20372032 30313220 32333a32
0008040 =A033= 202020 20202020 00000000 00000000
0008050 =A000305600 00563000 00= 000000 00000000
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^ = =A0 =A0 =A0 =A0 ^^^^^^^
volume size in bytes (should this be in logical blocks?)

0008060 =A000000000 00000000 00000000 00000000
0008070 =A0= 00000000 00000000 01000001 01000001
0008080 =A000080800 0a000000 = 0000000a c60a0000
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^ ^^^^
Blo= ck size, 2K

0008090 =A000000000 00000ac7 000= 00000 2200c20a
00080a0 =A000000000 0ac20010 00000000 10007005
00080b0 =A007151737 00020000 01000001 01003956


The size of the = iso given by ls is=A05656576,=A00x00565000
which is close e= nough to 0x563000 in bytes.

=A0I xd a = 90M linux iso I have and got:

0008000 =A001434430 30310100 4c494e55 = 58202020
0008010 =A020202020 20202020 20202020 20202020
0008020 =A020202020 20202020 4344524f 4d202020
0008030 =A0202020= 20 20202020 20202020 20202020
0008040 =A020202020 20202020 00000000 00000000
0008050 =A0fd= b30000 0000b3fd 00000000 00000000
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0^^^^^^^^^^^^^^^^^

90M/2K

0008060 =A000000000 00000000 00000000 00000000
0008070 =A00000000= 0 00000000 01000001 01000001
0008080 =A000080800 0a000000 0000000= a 14000000
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^
2K block size
0008090 =A000000000 00000016 00000000 22001800
00080a0 =A000= 000000 00180008 00000000 08006b05
00080b0 =A01808100a 20020000 01= 000001 01002020

So the size should be = in Blocks and it is in bytes, this is why it is wrong.

I don't understand why k3b reports doub= le the size because it
is much more. Unless I am not seeing= something...

G.






On Fri, Jun 28, 201= 3 at 8:57 PM, Gorka Guardiola <paurea@gmail.com> wrote:

page 19:


Volume Space Size (BP 81 to 88)=A0
=
This field shall specify as a 32-bit number the number of Logical Bloc= ks in which the Volume Space of the=A0
volume is recorded.=A0
This field shall be recorded according to 7.3.3.

<= div>





--
- curiosity = sKilled the cat
--089e01538d54057d1a04e03c6914--