in-core pointers to summary information. An array in this region
(fs_csp) could overflow on filesystems with a very large number of
cylinder groups (~16000 on i386 with 8k blocks). When this happens,
other fields in the superblock get corrupted, and fsck refuses to
check the filesystem.
Solve this problem by replacing the fs_csp array in 'struct fs'
with a single pointer, and add padding to keep the length of the
128-byte region fixed. Update the kernel and userland utilities
to use just this single pointer.
With this change, the kernel no longer makes use of the superblock
fields 'fs_csshift' and 'fs_csmask'. Add a comment to newfs/mkfs.c
to indicate that these fields must be calculated for compatibility
with older kernels.
Reviewed by: mckusick
touch ups. The cache needs to be flushed against block
reads, and a final flush at process termination to force the
backup superblocks to disk.
I believe this will allow 'make release' to complete.
Submitted by: Tor.Egge@fast.no
for large scsi disks with WCE = 0. This yields around a 7 times speedup
on elapsed newfs time on test disks here. 64k clusters seems to be the
sweet spot for scsi disks using our present drivers.
the mount is completely active, causing the next few commands attempting
to manipulate data on the mount to fail. mount_mfs's parent now tries
to wait for the mount point st_dev to change before returning, indicating
that the mount has gone active.
and we don't use the frags info, so why bother? More to the point, it
seems to result in an EXDEV error when the label is written out and we
lose because of it (don't know why though). This is a work-around and
is marked as such.
Add -v flag to newfs:
-v Specify that the partition does not contain any slices, and that
newfs should treat the whole partition as the file system. This
option is useful for synthetic disks such as ccd and vinum.
in rev.1.9). fsck uses the per-partition ffs-related information
in the label to find alternate superblocks when the main superblock
is hosed. Rev.1.9 broke this by deleting the code that wrote the
label.
PR: 2537
xref: fsck/setup.c rev.1.8
for filesystems with almost the maximum number of sectors. The maxiumum
is 2^31, but overflow is common for that size, and overflow normally
occurred here at size (2^31 - 4096).
size was rounded up to a multiple of the fragment size, but this
gave invalid file systems when the fragment size was > SBSIZE (fsck
aborts early on them). Now a fragment size of 32768 seems to work
(too-simple tests with fsck and iozone worked).
higher up in memory (0x0800000 upwards) rather than near zero (0x1000
for our qmagic a.out format). The method that mount_mfs uses to allocate
the memory within data size rlimits for the ram disk is entirely too much
of a kludge for my liking. I mean, if it's run as root, surely it makes
sense to just raise the resource limits to infinity or something, and if
it's a non-root user mount (do these work? with mfs?) it could just fail
if it's outside limits.
better hack in ffs_vfsops.c. The hack here restricted the maximum file
size to 2^39 bytes (512GB). fs_bsize * 2^31 - 1 (16TB for the default
blocksize of 8K) would have been better. There is no good way to remove
this limit on old BSD4.4 file systems.
This makes configuration of mfs /tmp on diskless clients more intuitive
for people like me, that have used this feature on NetBSD and SunOS.
Using the -T option and /dev/null, while already supported,
is neither intuitive nor documented in the handbook.
Obtained from: NetBSD
it's internal malloc() implementation to try and avoid overstepping it's
resource limits (yuk!). Remain using libc's malloc(), but check the
resource limits right before trying to malloc the ramdisk space and leave
some spare memory for libc. In Andrey's words, the internal malloc
was "true evil".. Among it's sins is it's ability to allocate less memory
than asked for and still return success. stdio would just love that. :-)
Reviewed by: ache
