>>>>> "kd" == Krunal Desai <mov...@gmail.com> writes:
kd> http://support.microsoft.com/kb/<whatever>
dude.....seriously?
This is worse than a waste of time. Don't read a URL that starts this
way.
kd> Windows 7 (even with SP1) has no support for 4K-sector
kd> drives.
NTFS has 4KByte allocation units, so all you have to do is make sure
the NTFS partition starts at an LBA that's a multiple of 8, and you
have full performance. Probably NTFS is the reason WD has chosen
4kByte.
Linux XFS is also locked at 4kByte sector size, because that's the VM
page size and XFS cannot use any other block size than the page size.
so, 4kByte is good (except for ZFS).
kd> can you explicate further about these drives and their
kd> emulation (or lack thereof), I'd appreciate it!
further explication: all drives will have the emulation, or else you
wouldn't be able to boot from them. The world of peecees isn't as
clean as you imagine.
kd> which 4K sector drives offer a jumper or other method to
kd> completely disable any form of emulation and appear to the
kd> host OS as a 4K-sector drive?
None that I know of. It's probably simpler and less silly to leave
the emulation in place forever than start adding jumpers and modes and
more secret commands.
It doesn't matter what sector size the drive presents to the host OS
because you can get the same performance character by always writing
an aligned set of 8 sectors at once, which is what people are trying
to force ZFS to do by adding 3 to ashift. Whether the number is
reported by some messy new invented SCSI command, input by the
operator, or derived by a mini-benchmark added to
format/fmthard/zpool/whatever-applies-the-label, this is done once for
the life of the disk, and after that happens whenever the OS needs
this number it's gotten by issuing READ on the label. Day-to-day, the
drive doesn't need to report it. Therefore, it is ``ability to
accomodate a minimum-aligned-write-size'' which badly people want
added to their operating systems, and no one sane really cares about
automatic electronic reporting of true sector size.
Unfortunately (but predictably) it sounds like if you 'zfs replace' a
512-byte drive with a 4096-byte drive you are screwed. therefore even
people with 512-byte drives might want to set their ashift for
4096-byte drives right now. This is another reason it's a waste of
time to worry about reporting/querying a drive's ``true'' sector size:
for a pool of redundant disks, the needed planning's more complicated
than query-report-obey.
Also did anyone ever clarify whether the slog has an ashift? or is it
forced-512? or derived from whatever vdev will eventually contain the
separately-logged data? I would expect generalized immediate Caring
about that since no slogs except ACARD and DDRDrive will have 512-byte
sectors.
pgpdnTloWn49S.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
