Manuel Bouyer writes:
> On Mon, Mar 27, 2006 at 09:36:40AM -0500, George Georgalis wrote:
> > >Seagate gets it wrong. 268435455 is 0xfffffff, a valid sector number
> > >for LBA but which is not handled properly by seagate firmwares.
> > >The workaround is to use LBA48 for this sector number.
> > >
> > >The attached patch should catch all seagate drives that needs it; it's in
> > >current but not in 3.0.
> > 
> > humm, this is starting to remind me of a similar issue I came
> > across in Linux. the patch caused the disk bandwidth to drop by
> > about 65%. Is that the case here? I would really prefer to
> > mark that block as in use...
> 
> I don't know as I don't have such drives here to test. But you could test
> by yourself.
> But if using LBA48 cause a 65% performance drop for these drives, they're
> even more buggy than I though :) Note that LBA48 is required for any sector
> above 128G.

I get 65MB/sec from one of these: 

wd0 at atabus0 drive 0: <ST3250824A>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 232 GB, 484521 cyl, 16 head, 63 sec, 512 bytes/sect x 488397168 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
wd0(viaide0:0:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using DMA)

which requires the quirk...  I didn't see a perf drop after patching 
my 3.0 kernel to deal with the quirk...  (Reconstruct of a RAID 1 set 
cruised along at 65MB/sec until it hit 0xfffffff and died.  After 
building a kernel w/ the quirk, reconstruction again was cruising at 
65MB/sec and finished just fine.. (it slowed down some for inner 
tracks, yes...))

Later...

Greg Oster