>> [...], there's a lot of history behind the notion that userland >> alignment of write() buffers affects, at most, performance, to the >> point where I consider it part of the interface. > Not on access to raw devices it isn't, and never was - what Erik Fair > said [...] was 100% correct - if you're using a raw device, it is up > to the application to meet whatever the requirements of that > particular device are, [...]
This would mean that raw devices as interfaces to disks are essentially useless. It becomes impossible to write _anything_ that works on "raw disks", because you don't know what restrictions might be demanded by the next disk device to come along. Indeed, it's entirely possible that two devices might make mutually incompatible demands, making it impossible to support both of them with the same code. Do we really want fsck_ffs_sd, fsck_ffs_xy, fsck_ffs_ld, fsck_ffs_wd, etc? That's where this is going. I think it would be a major step backwards philosophically and would definitely be a major step backwards in practice. And, for the specific case that started this off, that's not what's going on; it does write 64K of the 4M, so it clearly doesn't mind the alignment. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
