> maybe virtual 512 byte sectors are actually not that evil:
> Imagine a NORMAL 4096 byte sector based FAT32 filesystem.
> ...

Actually they are, or at least potentially are, at least from a compatibility 
perspective.  In the case of USB, the SCSI protocol is normally used.  The 
sector size is not simply stored on the disk (in the BPB's).  It is also stored 
"outside" the disk in the SCSI "overhead" that is part of the initialization 
process, and those can't be virtualized (there's more than one of them).  The 
sector size that the SCSI "overhead" tells you and what's stored on the disk 
itself need to be exactly the same, or you'll likely to run into problems 
somewhere that will either prevent a disk from being recognized, or contaminate 
the data.

> BPB CHS geometry differs - but does a disk with 4096 byte
> sectors allow CHS based access at all? I hope it does not.

Already answered by Bertho -- of course it does.  CHS addressing and 512-byte 
sectors aren't synonymous.

> ...
> Other operating systems would gain performance by pooling writes to
> MULTIPLE sectors which makes a very noticeable difference on flash
> based disks such as SSD or USB flash sticks.

Some DOS programs already do that, though usually only the ones that use 
low-level INT 13h access.  I don't think DOS itself ever does.

> ...
> This is why I suggest to first grow such a file to the final size,
> putting all FAT writes into ONE access and then writing the file's
> contents in large N kB chunks.

Excellent idea, especially with USB.

> Then I expect the side effect to be that the kernel "inflates" all
> sector-sized areas to 4096 bytes, to be prepared to handle 4096 byte
> sized sectors in SOME disks. For all old disks with classic 512 byte
> sectors, this means a lot of wasted space in RAM for each such
> buffer in memory. Unless I misunderstood the details, MS DOS would
> not adjust sizes on a per-buffer basis.

That is correct -- the buffers are all the same size, big enough for the 
largest sector of any disk.  It does indeed waste memory, especially if you set 
BUFFERS to a large number.  If somebody was ambitious enough, they might be 
able to implement dynamic buffer sizes, I suppose (I don't know what the 
"required" data structures for DOS Buffers, if there are any, are supposed to 
look like).

> You mean you know any sort of USB storage device which has native
> 2048 byte sectors? I thought that for flash and large disk formats,
> only 4096 was popular and 512?

No, I personally don't have anything except 512-byte sectors.  I just did 2048 
as an experiment to see if there were problems, while still keeping the size 
small enough that I didn't waste too much memory.

> So you actually do the "virtual trick" the other way around?  As
> mentioned above, that only works when all relevant structures on the
> actually-512-byte-per-sec disk are aligned to and sized in 2 kB
> boundaries, not counting the global offset of the partition, though.

Unless I'm misunderstanding what you're saying, it's not "the other way 
around".  If a buffer is 2048 and the sectors are only 512, the last 1536 bytes 
of the buffer are simply never used.  There aren't any cluster alignment issues.

> ...
> if we can "mount" a 4096 byte per sector disk in DOS, no matter what
> tool and operating system formatted / fdisked it then we can already
> enjoy using those disks :-)

Yes.  But for reasons already discussed, this should not be done by 
virtualizing the sector size -- that is asking for problems, IMHO.

> ...
> By the way, is the 55aa boot sector thing and similar flags for
> fsinfo and 2nd stage boot sectors on FAT32 always at the end of the
> sector or rather just at the end of the first 512 bytes of the
> sector?

Also already answered by Bertho.  It's always at offset 510 in the sector, not 
necessarily the end of the sector (the MBR and VBR's still need to fit in 512 
bytes even if the sector is larger).  If the sector size is larger than 512, 
you can use the rest of the sector to store other things if you want, though.

RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
Freedos-user mailing list

Reply via email to