summaryrefslogtreecommitdiffstats
path: root/UPDATING
diff options
context:
space:
mode:
authorbde <bde@FreeBSD.org>2007-07-12 16:09:07 +0000
committerbde <bde@FreeBSD.org>2007-07-12 16:09:07 +0000
commit01c1ec9b1ae5e546930028126ab6d950d401c786 (patch)
treeec9034244b2c722defe64190f00e6063e92ad1b7 /UPDATING
parent46995e966fea71f67bb69ba55d39bb676628444a (diff)
downloadFreeBSD-src-01c1ec9b1ae5e546930028126ab6d950d401c786.zip
FreeBSD-src-01c1ec9b1ae5e546930028126ab6d950d401c786.tar.gz
Fix some bugs involving the fsinfo block (many remain unfixed). This is
part of fixing msdosfs for large sector sizes. One of the fixed bugs was fatal for large sector sizes. 1. The fsinfo block has size 512, but it was misunderstood and declared as having size 1024, with nothing in the second 512 bytes except a signature at the end. The second 512 bytes actually normally (if the file system was created by Windows) consist of a second boot sector which is normally (in WinXP) empty except for a signature -- the normal layout is one boot sector, one fsinfo sector, another boot sector, then these 3 sectors duplicated. However, other layouts are valid. newfs_msdos produces a valid layout with one boot sector, one fsinfo sector, then these 2 sectors duplicated. The signature check for the extra part of the fsinfo was thus normally checking the signature in either the second boot sector or the first boot sector in the copy, and thus accidentally succeeding. The extra signature check would just fail for weirder layouts with 512-byte sectors, and for normal layouts with any other sector size. Remove the extra bytes and the extra signature check. 2. Old versions did i/o to the fsinfo block using size 1024, with the second half only used for the extra signature check on read. This was harmless for sector size 512, and worked accidentally for sector size 1024. The i/o just failed for larger sector sizes. The version being fixed did i/o to the fsinfo block using size fsi_size(pmp) = (1024 << ((pmp)->pm_BlkPerSec >> 2)). This expression makes no sense. It happens to work for sector small sector sizes, but for sector size 32K it gives the preposterous value of 64M and thus causes panics. A sector size of 32768 is necessary for at least some DVD-RW's (where the minimum write size is 32768 although the minimum read size is 2048). Now that the size of the fsinfo block is 512, it always fits in one sector so there is no need for a macro to express it. Just use the sector size where the old code uses 1024. Approved by: re (kensmith) Approved by: nyan (several years ago for a different version of (2))
Diffstat (limited to 'UPDATING')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud