You may have seen my cunning plan:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=883310+0+current/freebsd-stable
I've been doing some testing today. The first of my tests comparing
partitions aligned on a 4KB boundary are in. I created a 5x2TB zpool,
each of which was set up like this:
gpart add -b 1024 -s 3906824301 -t freebsd-zfs -l disk01 ada1
or
gpart add -b 34 -s 3906824301 -t freebsd-zfs -l disk01 ada1
Repeat for all 5 HDD. And then:
zpool create storage raidz2 gpt/disk01 gpt/disk02 gpt/disk03 gpt/disk04
gpt/disk05
Two Bonnie-64 tests:
First, with -b 34:
# ~dan/bonnie-64-read-only/Bonnie -s 5000
File './Bonnie.12315', size: 5242880000
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU /sec %CPU
5 110.6 80.5 115.3 15.1 60.9 8.5 68.8 46.2 326.7 15.3 469 1.4
And then with -b 1024
# ~dan/bonnie-64-read-only/Bonnie -s 5000
File './Bonnie.21095', size: 5242880000
Writing with putc()...done
Rewriting...^[[1~done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU /sec %CPU
5 130.9 94.2 118.3 15.6 61.1 8.5 70.1 46.8 241.2 12.7 473 1.4
My reading of this: All M/sec rates are faster except sequential input.
Comments?
I'll run -s 20000 and -s 50000 tests overnight and will post them in the
morning.
Sunday, I'll try creating a 7x2TB array consisting of 5HDD and two
sparse files and see how that goes. Here's hoping.
Full logs here, including a number of panics:
http://beta.freebsddiary.org/zfs-with-gpart.php
--
Dan Langille - http://langille.org/
On 7/24/2010 10:44 PM, Dan Langille wrote:> I'll run -s 20000 and -s 50000 tests overnight and will post them in the > morning.The -s 20000 results are in: -b 34: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU /sec %CPU 20 114.1 82.7 110.9 14.1 62.5 8.9 73.1 48.8 153.6 9.9 195 0.9 -b 1024: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU /sec %CPU 20 111.0 81.2 114.7 15.1 62.6 8.9 71.9 47.9 135.3 8.7 180 1.1 Hmmm, seems like the first test was better... -- Dan Langille - http://langille.org/
On 7/24/2010 10:44 PM, Dan Langille wrote:> You may have seen my cunning plan: > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=883310+0+current/freebsd-stable > > > I've been doing some testing today. The first of my tests comparing > partitions aligned on a 4KB boundary are in. I created a 5x2TB zpool, > each of which was set up like this: > > gpart add -b 1024 -s 3906824301 -t freebsd-zfs -l disk01 ada1 > or > gpart add -b 34 -s 3906824301 -t freebsd-zfs -l disk01 ada1 > > Repeat for all 5 HDD. And then: > > zpool create storage raidz2 gpt/disk01 gpt/disk02 gpt/disk03 gpt/disk04 > gpt/disk05 > > Two Bonnie-64 tests: > > First, with -b 34: > > # ~dan/bonnie-64-read-only/Bonnie -s 5000 > File './Bonnie.12315', size: 5242880000 > Writing with putc()...done > Rewriting...done > Writing intelligently...done > Reading with getc()...done > Reading intelligently...done > Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU /sec %CPU > 5 110.6 80.5 115.3 15.1 60.9 8.5 68.8 46.2 326.7 15.3 469 1.4 > > > > > And then with -b 1024 > > # ~dan/bonnie-64-read-only/Bonnie -s 5000 > File './Bonnie.21095', size: 5242880000 > Writing with putc()...done > Rewriting...^[[1~done > Writing intelligently...done > Reading with getc()...done > Reading intelligently...done > Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU /sec %CPU > 5 130.9 94.2 118.3 15.6 61.1 8.5 70.1 46.8 241.2 12.7 473 1.4 > > > My reading of this: All M/sec rates are faster except sequential input. > Comments? > > I'll run -s 20000 and -s 50000 tests overnight and will post them in the > morning.Well, it seems I'm not sleeping yet, so: -b 34 -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU /sec %CPU 50 113.1 82.4 114.6 15.2 63.4 8.9 72.7 48.2 142.2 9.5 126 0.7 -b 1024 -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU /sec %CPU 50 110.5 81.0 112.8 15.0 62.8 9.0 72.9 48.5 139.7 9.5 144 0.9 Here, the results aren't much better either... am I not aligning this partition correctly? Missing something else? Or... are they both 4K block aligned? -- Dan Langille - http://langille.org/
Am 26.07.2010 03:07, schrieb perryh@pluto.rain.com:> Dmitry Morozovsky <marck@rinet.ru> wrote: >> ... sector numbers (in CHS address method) >> [start] at 1 (which always suprized me ;) > > This goes back at least as far as soft-sectored 8" diskettes > in the CP/M era. > > IIRC, physical sector 0 of each track contained the C number, > possibly the H, and a list of the remaining sectors on the track > including the size of each sector -- even within a single track > the sectors did not all have to be the same size.This is extremely off-topic, and therefor, I?ll only say, that the above is not true for 8" diskettes nor for CP/M. I can only guess, that there is a track 0 and not a sector with that number because the first track was reserved for system internal use (e.g. held at least the CCP in case of CP/M). I?m quite sure, that FDCs generally supported sector numbers from 0 to 254 (with 255 reserved as a wildcard in certain commands). But this is all really off-topic ... Regards, STefan