Re: newfs and mount vs. half-baked disks
From: Bruce Evans (bde_at_zeta.org.au)
Date: 11/10/03
- Previous message: Kirk McKusick: "Re: newfs and mount vs. half-baked disks"
- In reply to: Kirk McKusick: "Re: newfs and mount vs. half-baked disks"
- Next in thread: Kirk McKusick: "Re: newfs and mount vs. half-baked disks"
- Reply: Kirk McKusick: "Re: newfs and mount vs. half-baked disks"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 10 Nov 2003 18:01:59 +1100 (EST) To: Kirk McKusick <mckusick@beastie.mckusick.com>
On Sun, 9 Nov 2003, Kirk McKusick wrote:
> > From: Bruce Evans <bde@zeta.org.au>
> > The block count is in units of sector size, so disks much larger than
> > 2TB can be supported by disklabel using (fake if necessary) sector sizes
> > larger than 512. File systems need to use similarly large block (fragment
^^^^^^^^
> > for ffs) sizes, and some patches are needed for reading superblocks if
^^^^^^^
> > the sector size is larger than 8K. Since ffs uses a block size of 16K
> > by default, a sector size of 16K are not unreasonable and this is sufficent
> > for disks smaller then 64TB.
>
> Actually, FFS requires its fragment size be no smaller than the sector size
> (since it presumes that it cannot do read/write in smaller than sector
> sizes). So, on a 16K filesystem, you get 2K fragments. So your hack only
> gets you to 8TB which is not going to last long at current disk growth
> rates.
This point was noted in the underlined phrase. The blocks size for ffs is
actually the fragment size in this context. So fragments would be as
large as necessary (16K if that is the sector size), and the block size
(he one given by newfs's -b parameter) would be larger. A fragment size
of 16K may even be the right size for very large disks. My benchmarks
say that 16K/8K block/fragment size is not much slower than 16K/2K on
a 60GB disk, but 16K/16K and 32K/any are significantly slower.
Bruce
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Kirk McKusick: "Re: newfs and mount vs. half-baked disks"
- In reply to: Kirk McKusick: "Re: newfs and mount vs. half-baked disks"
- Next in thread: Kirk McKusick: "Re: newfs and mount vs. half-baked disks"
- Reply: Kirk McKusick: "Re: newfs and mount vs. half-baked disks"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: newfs and mount vs. half-baked disks
... FFS requires its fragment size be no smaller than the sector size ... The blocks
size for ffs is ... > actually the fragment size in this context. ...
FreeBSD filesystem (e.g., what would fit on a 60Gb 16K/2K filesystem ... (freebsd-arch) - Re: preparing an ext2fs on OpenBSD
... I run into some problems with my disk server box after one power-out: ... 48MB
of RAM and 200GB of HDD with OpenBSD seems to ... be a bad idea since the disk check
requires so much RAM with ffs. ... (comp.unix.bsd.openbsd.misc) - Re: Drive has less space with UFS
... > three of them are still using the ext2 file system. ... > how I setup
the UFS drive (FFS has been built into the kernel if that makes ... A certain percentage
of your disk is reserved space. ... (comp.unix.bsd.freebsd.misc) - Re: any real documentation of the boot2 prompt?
... 1: FFS ... and enable the disk for booting. ... but I didn't need
any help with the SCSI BIOS. ... Apparently 3ware only shows a single LUN to the
BIOS, even when it shows multiple LUNs to the booted system. ... (freebsd-stable)