Re: gpart -b 34 versus gpart -b 1024
On 25.7.2010 5:58, Dan Langille wrote: >> ---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 >> 5 130.9 94.2 118.3 15.6 61.1 8.5 70.1 46.8 241.2 12.7 473 1.4 > 50 113.1 82.4 114.6 15.2 63.4 8.9 72.7 48.2 142.2 9.5 126 0.7 > 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? As others have said - your drives probably don't have the alignment requiremnt, but your posts show in an excellent example why benchmarking file systems is complicated and how easy it is to measure noise instead of the real thing. To measure real performance in your case, you would either need to benchmark at a layer beneath the file system or with a simple file system which does alwasy predictable io patterns. It's hard to do with zfs with raidz - afaik even accessing the "raw" zvols translates into complex IOs (they are COW). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On 7/19/2010 12:00 PM, Harald Schmalzbauer wrote:
**/
-/*$FreeBSD: src/sys/dev/e1000/if_igb.h,v 1.4.2.2.2.1 2010/06/14 02:09:06
kensmith Exp $*/
+/*$FreeBS
Haralad:
It looks like your patch is identical to the patch RFP'd from HEAD
to branches/stable/8 on 06/18/2010 (aka, SVN r209309?)
This includes the cumulative backport of changes in HEAD from
r208117 all the way to r209259 (but not 209959, which addresses
the TX checksum panic?)
Just to confirm: This fixes the duplex problems for you?
If so, odd -- I coped all of e1000/*.{c.h} from 8/stable/.../e1000/*
on 07/17/2010 into releng/8.1/sys/dev/e1000/* and am still seeing
the duplex problem after a full rebuild.
I've been laboring under the assumption that SVN r209238 fixed
my problem, but it doesn't appear so from my backport testing.
I'll try modifying your patch to include r209259 -> 209959 from
HEAD as well and go from there.
~BAS
PS. Maybe my lurid language has cursed me and I have to make peace
with the universe first. Now, everyone reach under their chairs
and take the 5 dried grams of shrooms I taped there.
Then send in Vanilla Ice.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gpart -b 34 versus gpart -b 1024
Am 26.07.2010 03:07, schrieb per...@pluto.rain.com: > Dmitry Morozovsky 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On 26.07.2010 18:19, Brian A. Seklecki (CFI NOC) wrote:
> On 7/19/2010 12:00 PM, Harald Schmalzbauer wrote:
>> **/
>> -/*$FreeBSD: src/sys/dev/e1000/if_igb.h,v 1.4.2.2.2.1 2010/06/14
>> 02:09:06 kensmith Exp $*/
>> +/*$FreeBS
>
>
> Haralad:
>
> It looks like your patch is identical to the patch RFP'd from HEAD
> to branches/stable/8 on 06/18/2010 (aka, SVN r209309?)
>
> This includes the cumulative backport of changes in HEAD from
> r208117 all the way to r209259 (but not 209959, which addresses
> the TX checksum panic?)
Looks like I really missed r209259
> Just to confirm: This fixes the duplex problems for you?
No, I haven't done further tests regarding the duplex problem.
> If so, odd -- I coped all of e1000/*.{c.h} from 8/stable/.../e1000/*
> on 07/17/2010 into releng/8.1/sys/dev/e1000/* and am still seeing
> the duplex problem after a full rebuild.
>
> I've been laboring under the assumption that SVN r209238 fixed
> my problem, but it doesn't appear so from my backport testing.
>
> I'll try modifying your patch to include r209259 -> 209959 from
> HEAD as well and go from there.
Sorry for the hassle, I shouldn't have posted this patch without
verification.
-Harry
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
nfsv4 strangeness
Greetings fellow list-mates. I have been trying to set up a zfs filesystem in order to share it over the network using nfs. The filesystem was easy enough to set up. As long I was using nfsv3, everything was in order. I was able to mount the share (from my archlinux desktop pc). My headaches started when I tried to enable the nfsv4 server. When I added nfsv4_server_enable="YES" to the rc.conf file, I started getting errors and I could not mount the share at all. Right now, the output I get while mounting is: mount.nfs4: timeout set for Tue Jul 27 06:14:56 2010 mount.nfs4: trying text-based options 'addr=192.168.2.100,clientaddr=192.168.2.64' mount.nfs4: mount(2): Permission denied mount.nfs4: access denied by server while mounting files:/temper The last line suggests that it is the server's fault, and that's why I'm here. After searching the web for any clue I admit I haven't found a thing. The server is running 8.1-RELEASE amd64 with the generic kernel. More or less all files are the ones that come with the default installation. As for the filesystem: [r...@files ~]# zfs get sharenfs temper NAMEPROPERTY VALUE SOURCE temper sharenfs onlocal All pointers are welcome. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
