Re: Problem identified: WAPL/RAIDframe performance problems

2012-12-01 Thread Mouse
>>> things. What I care about is the largest size "sector" that will (in > ^^^ >>> the ordinary course of things anyway) be written atomically. >> Then those are 512-byte-sector drives [...] > No; because I can do 4K atomic writes, I want to know about that.

Re: Making forced unmounts work

2012-12-01 Thread David Holland
On Thu, Nov 29, 2012 at 06:19:37PM +0100, J. Hannken-Illjes wrote: > >> In short the attached diff: > >> > >> - Adds a new kernel-internal errno ERESTARTVOP and changes VCALL() to > >> restart a vnode operation once it returns ERESTARTVOP. > >> > >> - Changes fstrans_start() to take an opt

Re: Problem identified: WAPL/RAIDframe performance problems

2012-12-01 Thread David Holland
On Sun, Dec 02, 2012 at 01:32:17AM +, Julian Yon wrote: > > I don't care about the block granularity of the interface. (Unless I > > suppose it's larger than the atomic write size; but that would be > > weird.) > > If it's smaller than the atomic write size that's equally weird. > Becaus

Re: Problem identified: WAPL/RAIDframe performance problems

2012-12-01 Thread David Holland
On Sat, Dec 01, 2012 at 07:07:36PM -0500, Mouse wrote: > >> Neither. The sector size claimed to the host should equal both the > >> sector size on the media and the granularity of the interface. > > As a consumer of block devices, I don't care about either of these > > things. What I care abo

Re: Problem identified: WAPL/RAIDframe performance problems

2012-12-01 Thread Julian Yon
On Sat, 1 Dec 2012 23:46:07 + David Holland wrote: > I don't care about the block granularity of the interface. (Unless I > suppose it's larger than the atomic write size; but that would be > weird.) If it's smaller than the atomic write size that's equally weird. Because that implies that

Re: Problem identified: WAPL/RAIDframe performance problems

2012-12-01 Thread Mouse
>> Neither. The sector size claimed to the host should equal both the >> sector size on the media and the granularity of the interface. > As a consumer of block devices, I don't care about either of these > things. What I care about is the largest size "sector" that will (in > the ordinary course

Re: Problem identified: WAPL/RAIDframe performance problems

2012-12-01 Thread David Holland
On Sat, Dec 01, 2012 at 04:27:14PM -0500, Mouse wrote: > Neither. The sector size claimed to the host should equal both the > sector size on the media and the granularity of the interface. As a consumer of block devices, I don't care about either of these things. What I care about is the larges

Re: re(4) MAC address

2012-12-01 Thread Izumi Tsutsui
Frank Wille wrote: > > Probably it's defined by hardware vendors, not chip. > > > > The old RTL8139 (RTL8169 has compat mode) seems to read MAC address > > from EEPROM and those values are stored into RTK_IDRn registers. > > Who writes it into the IDRn registers? The firmware? The driver? Or the

Re: re(4) MAC address

2012-12-01 Thread Frank Wille
Izumi Tsutsui wrote: On 02.12.12 00:40:44 you wrote: >> I found out that NetBSD's re(4) driver is reading the MAC from EEPROM >> while PPCBoot and Linux are reading it from the chip's ID-registers >> (RTK_IDRn). >> >> What is correct? This is a Realtek 8169S: > > Probably it's defined by hardwar

Re: Problem identified: WAPL/RAIDframe performance problems

2012-12-01 Thread Mouse
>> These disks lie about their actual sector size. > These disks just follow their specification. That's as meaningless as...on, to pick an unreasonably extreme example, a hitman saying "I was just following orders". > They also report the true sector size. Not according to the documentation, at

Re: Problem identified: WAPL/RAIDframe performance problems

2012-12-01 Thread Michael van Elst
On Fri, Nov 30, 2012 at 12:00:52PM +, David Laight wrote: > On Fri, Nov 30, 2012 at 08:00:51AM +, Michael van Elst wrote: > > da...@l8s.co.uk (David Laight) writes: > > > > >I must look at how to determine that disks have 4k sectors and to > > >ensure filesystesm have 4k fragments - regard

Re: re(4) MAC address

2012-12-01 Thread Izumi Tsutsui
> I found out that NetBSD's re(4) driver is reading the MAC from EEPROM > while PPCBoot and Linux are reading it from the chip's ID-registers > (RTK_IDRn). > > What is correct? This is a Realtek 8169S: Probably it's defined by hardware vendors, not chip. The old RTL8139 (RTL8169 has compat mode)

re(4) MAC address

2012-12-01 Thread Frank Wille
Hi, I was testing a NH-230/231 NAS (running sandpoint) and wondered why the PPCBoot firmware and the previously installed Linux used a different MAC address than NetBSD does. I found out that NetBSD's re(4) driver is reading the MAC from EEPROM while PPCBoot and Linux are reading it from the chip