Hi, > > As I don't have any of the various vendors disks. I would expect > somewhere, soon they will have drives that kowtow to 512 byte block > to help windows and MBR booting. I know WD has a Address+1 patch > to make MBR work in 512byte mode. This is not alpha specific. Proper partitioning on linux is actually quite simple, and resolves any unaligning problems. I always align each partition on such disks to 4MB bonduary actually (much more than needed, but keeps things simpler :D ), especially usefull on SSD drives as they often operate in blocks of approximetly this size (sometimes maybe 64MB). This also makes room for various bootloaders before partition, without risk they will overwrite my actuall data after them. I personanly think this address+1 patch, introduces more problems, especially on linux it makes things worse, but I understand it is mainly for stupid windows installers (especially old ones). > > Since the LBA addressing tops at 2.7TB, I don't know if you can get > at the full 3TB without there being some way to address it in 4K > chunks. Again, nothing alpha-specific. If it will be solved in ATA or SCSI protocol, or other interfaces, it should work. Not nacassarly we will be able to boot from such device on Alphas, but it will work after boot. Eventually it could work similary how LILO had limitation of <1024 cylinders for kernels in /boot :D, but this is just speculation, as we are not yet in the future, (but there is already 3TB drives right?). > > Since it is the near future though, has better fault (per block at > least) Not nacassarly. Vendors will probably use it to the limits to provide same fault tolerance, and offer bigger storage. But depends on target market of couse. Maybe slightly better relibability, as bigger storage means more longly-not-used-data, and more transactions, and more agregated transfers, so this aspects will make errors apper more often even if error have smaller probability of occuring. This is also reasons things like ZFS, or btrfs is much more important this days. (BTW. I'm testing zfs-fuse on linux alpha). > tolerance ( 3 bits correction, I may be wrong) and Oh. It is much more, I assure you. It is something like 200 BYTES for each 4096 byte sector. And is pretty complicated. :) > reading/writing is 4K chunks is much more efficient than 8 512 byte > reads, and writing 512 means that the drive reads the 4K block, puts > the 512 bytes in the right place and re-writes it > we can still make it all behave better, possibly. Well, it actually do not make big difference. Operating systems and hard disks already do readahead, and it is in mosts cases much more than just 8 sectors, more like 64, or 256 sectors! In terms in performance there is probably less overheads in maintaining associativity in the cache, and less ECC processing overheads in total (because checksum-for-4k < 8*chekcsum-for-512, in terms of size). Similary for writing we use write cache (well if we have enabled them, often not, as this unfortunetly have some pretty nasty crash bahaviour), which will often merge multiple write requests (linux is already merging such small writes into bigger ones already, [ignore o_sync/o_direct/fsync/dsatasync issues]). And again if we have all partitions, LVMs, DMs, cryptoloops, etc, alligned properly (and it is quite simple to do so, if you do everything cerfully), then underlaying blocks (from ext3 for example), should NOT make such stupid things as you described. ;) Again, nothing alpha-specific. :) > Yes, I forgot about Milo, and we might need to play in the boot > prom. (It has been a few years).) I never used it. But it looks slightly more friendly than aboot. Regards, Witek -- Witold Baryluk
Attachment:
signature.asc
Description: Digital signature