On Thursday May 17, [EMAIL PROTECTED] wrote: > At 4:32 PM +1000 2001-05-17, Neil Brown wrote: > >Linus, > > The current raid1/raid5 resync code requests resync in units of 1k > > (though the raid personality can round up requests if it likes). > > This interacts badly with filesystems that do IO in 512 byte blocks, > > such as XFS (because raid5 need to use the same blocksize for IO and > > resync). > >... > >+ window = MAX_READAHEAD*(PAGE_SIZE/512); > >+ printk(KERN_INFO "md: using %dk window, over a total of %d > >blocks.\n",window/2,max_sectors/2); > > ... > >- bh->b_blocknr = block_nr; > >- bsize = 1024; > >+ bh->b_blocknr = sector_nr; > >+ bsize = 512; > >... > >- return (bsize >> 10); > >+ return (bsize >> 9); > > While it seems sort of ugly for code at the level of md to have > explicit knowledge of sector size at all, would this not (at least) > be a good opportunity to replace the literal constants with (at > least) #defines, and avoid all these embedded magic numbers? > -- > /Jonathan Lundell. The understanding that "a sector is 512bytes" appear implicitly in lots of places. I don't think there is much value in replacing every "512" by "BYTES_PER_SECTOR" and "9" by "SECTOR_SHIFT" everywhere. It is a real-world fact that some (many) devices use 512 byte "sectors" and while some use larger sectors, none (that I know of) use smaller. More annoying I think is the fact that device sizes are stored in units of 1K instead of the universal "sector". NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED]
