On Tue, Jan 16, 2007 at 10:59:11AM +0900, Takayuki Tsunakawa wrote:
> From: "Magnus Hagander" <[EMAIL PROTECTED]>
> > ITAGAKI Takahiro wrote:
> >> Do you mean there are drives that have larger sector size than 8kB?
> >> We've already put the xlog buffer along the alignment of
> >> ALIGNOF_XLOG_BUFFER (typically 8192 bytes).
> >> But if there are such drives, using FILE_FLAG_NO_BUFFERING is
> harmful!
> >
> > Yes. I have heard this can happen with certain SAN drives. I haven't
> > seen it myself, and I can't seem to find a reference right now :-)
> But I
> > do recall having read about th need to check the sector size and
> > specifically align it, because some do have that problem.
> I think many people can benefit from Itagaki-san's proposal, and
> NO_BUFFERING should be default.  Isn't it very rare that disks with
> sector size larger than 8KB are used? 

Definitly very rare.

> Providing a way (such as
> wal_sync_method) to avoid NO_BUFFERING is sufficient for people in
> rare environments.  Or, by determining the sector size with
> GetDiskFreeSpaceEx(), we could auto-switch to not using NO_BUFFERING
> when the sector size is larger than 8KB.

I think the second one is better.

> I wonder whether GetDiskFreeSpaceEx() tells us the right sector size
> configured by SAN tools.

It should. If it doesn't, then there are likely to be other issues.

> And I wonder if Microsoft assumes a sector size larger than 4KB and
> NTFS works.  The following paragraph appears in the CreateFile page:
> One way to align buffers on integer multiples of the volume sector
> size is to use VirtualAlloc to allocate the buffers. It allocates
> memory that is aligned on addresses that are integer multiples of the
> operating system's memory page size. Because both memory page and
> volume sector sizes are powers of 2, this memory is also aligned on
> addresses that are integer multiples of a volume sector size. Memory
> pages are 4-8 KB in size; sectors are 512 bytes (hard disks) or 2048
> bytes (CD), and therefore, volume sectors can never be larger than
> memory pages.

Good question. Again, I have no firsthand info about systems with >4K
sectors. Obviously you have 2K sectors on CDs, but that doesn't really
apply to us because we don't run with our files on CD at all...

It *could* be someone who mixed up the difference between sector size
and NTFS block size (which is definitly supoprted up to 64K/block at

A quick google shows some inconclusive results :-)BUt look at for

This seems to indicate that *Windows* supports sector sizes >4K, but SQL
Server doesn't. But again, it could be a mixup between cluster and
sector size...


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to