ExtremeRAID with NV cache) and "dumb" (3ware 6410) ld providers.
Instead, use the default buffer queue policy.
With the 3ware adapter, using the read priority strategy instead of FCFS,
for three extractions of pkgsrc, took 329 seconds instead of 331 -- but
with a dramatic improvement in perceived system response (latency for
I/O outside the main stream).
With the Mylex adapter, the improvement was dramatic: using read priority
instead of FCFS yielded an improvement from 381 seconds to 135 seconds!
There was a less-noticeable improvement in perceived latency as well.
The other disk drivers currently hard-wired to FCFS or another policy
should probably be changed as well.
leave 4 bytes for the Windows NT Drive Serial Number (DSN) at 440-443
(as mbr_sector.mbr_dsn).
Ensure that all the MBR & PBR code reserves space for mbr_sector.mbr_dsn.
Leave the bootsel magic number at 444-445 as mbr_sector.mbr_bootsel_magic
(instead of mbr_sector.mbr_bootsel.mbrbs_magic), but use 0xb5e1 (MBR_BS_MAGIC)
instead of 0xaa55 (MBR_MAGIC) to indicate that this change has occurred.
Rework MBR_BS_NEWMBR to mean "mbr_bootsel has moved to 400".
Modify fdisk(8) to automatically relocate the mbr_bootsel from 404 to 400
if mbr_bootsel_magic is the old value (0xaa55), and unset MBR_BS_NEWMBR
to flag that new mbr_bootsel code must be used if updating the MBR.
These changes fixes a problem where Windows 2000 or Windows XP would corrupt
the last 3 bytes + NUL of MBR partition 3's bootsel name if the bootsel name
was 5 characters long, replacing bytes 6-9 with the DSN.
Also, by explicitly reserving the space for the DSN we prevent problems in the
future if non bootsel MBR or PBR code had other information at bytes 440-443.
location where we expect to find an ffsv2 superblock.
It could be the first alternate for a ffsv1 filesystem with 64k blocks.
Fixes part of PR kern/24809
location where we expect to find an ffsv2 superblock.
It could be the first alternate for a ffsv1 filesystem with 64k blocks.
Fixes part of PR kern/24809
sufficient to clobber this nasty little bug. The behaviour observed
was a panic when doing a 'raidctl -f' on a component when DAGs were
in flight for the given RAID set. Unfortunatly, the faulty behaviour
was very intermittent, and it was difficult to not only reliably
reproduce the bug (nor determine when it was fixed!) but also to even
figure out what might be the cause of the problem.
The real issue was that ci_vp for the failed component was being
set to NULL in rf_FailDisk(), but with DAGs still in flight, some
of them were still expecting to use ci_vp to determine where to
read to/write from!
The fix is to call rf_SuspendNewRequestsAndWait() from rf_FailDisk()
to make sure the RAID set is quiet and all IOs have completed before
mucking with ci_vp and other data structures. rf_ResumeNewRequests()
is then used to continue on as usual.
finding an ffsv1 sb at 64k.
Also stop it playing with fs that have 'FS_FLAGS_UPDATED' set.
It certainly doesn't act on that falg, and my guess is that it is
playing the pre-ffsv2 fs.
Fixes part of PR kern/24809
location where we expect to find an ffsv2 superblock.
It could be the first alternate for a ffsv1 filesystem with 64k blocks.
Fixes part of PR kern/24809
