Swift Griggs <swiftgriggs%gmail.com@localhost> writes: > On Wed, 25 Nov 2015, Greg Troxel wrote: >> We're seeing smaller disks with 4K sectors or larger flash erase >> blocks and 512B interfaces now. > > Those larger erase blocks (128k?!) would seem to be a big problem if > you'd rather stick to a smaller alignment or file system block > size. However, maybe I'm missing something about the interplay between There's no good reason (other than a bit of space wastage once) not to align (defined as fs starting on multiple of something). fs block size is another story. But if you want to write 8K and there's a 128K erase block, that's how it is. Hopefully multiple writes coalesce. The thing that should be avoided is writing 4K and having that split into two 4K chunks. > things like inode sizes and any relationship with the erase block > size. For example, if you were using an 8K block size I'd think a 128k inodes are actually much smaller. We are talking about block sizes of data. > erase block size would blow things up nicely when you blew way past > the 8k block you originally wanted to clear. It is more that the flash layer needs to rerite the whole chunk. That becomes just the way it is with big erase blocks, mostly. Filesystems try to write sequential blocks when they can. ZFS further integrates fs and raid, but NetBSD's ZFS is old and not quite right. >> That avoids the alignment issue, but requires filesystem/kernel >> support. I am pretty sure netbsd-7 is ok with that but I am not sure >> about earlier. > > Interesting. For some reason I have it in my head that many EMC SANs > of various stripes (and I know for sure the XtremeIO stuff) uses 4k > block sizes. I've used NetBSD in the past in EMC environments and seen > moderate (but not what I'd call "high") performance vis-a-vis other > (Linux and/or Solaris) hosts. I wonder if this was a factor. I'll have > to test with Netbsd 7, now. Sounds fun. With a SAN (vs NAS), presumably there is iscsi or some other SAN protocol? Does that *protocol* expose 4K blocks? Maybe this works in -6 too; I only recently have a native 4K disk (vs 4K/512),and I don't have an EMC SAN. > I did learn that 4k seems to be the smallest allowable size (line 141 > in fs.h #define MINBSIZE 4096). It sounds like that's the smallest > since a cylinder group block struct needs a 4k space to be workable. I think 4KB is not because it's the smallest that's workable efficiency wise, but because there is a fragsize which is blocksize/8, and a single 512B sector is the smallest fragment. >> I guess you can put it that way, saying otherwise we would always >> start at 2048 and use 32K or even 64K blocks. > > That doesn't seem too wasteful to me, but I'm ready for some embedded > systems guy to lecture me. :-) Back when I was young, one of the first computer I used that actually had disks had a pair of 2.5 MB disks, with Sixth Edition Unix: https://en.wikipedia.org/wiki/RK05 which is about 4900 512-byte sectors on each. Using 2048 for alignment would have been unthinkable. But these are just historical curiousities now, along with the RX01 8" floppy.
Attachment:
signature.asc
Description: PGP signature