Re: newfs and mount vs. half-baked disks

From: Kirk McKusick (mckusick_at_beastie.mckusick.com)
Date: 11/11/03

  • Next message: Alexander Leidinger: "Re: Patches to compile the kernel with Intel's C/C++ compiler" 
    To: Bruce Evans <bde@zeta.org.au>
Date: Mon, 10 Nov 2003 20:40:30 -0800

    > Date: Mon, 10 Nov 2003 18:01:59 +1100 (EST)
    > From: Bruce Evans <bde@zeta.org.au>
    > To: Kirk McKusick <mckusick@mckusick.com>
    > cc: arch@freebsd.org
    > Subject: Re: newfs and mount vs. half-baked disks
    > X-ASK-Info: Whitelist match
    >
    > 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

    Using 16K/16K will not change the speed of operation appreciably, but
    it will *more than double* the space required to hold the typical
    FreeBSD filesystem (e.g., what would fit on a 60Gb 16K/2K filesystem
    will require 120Gb on a 16K/16K filesystem). This happens because
    most files on a typical filesystem are small. That is a poor tradeoff
    in my opinion.

            Kirk McKusick
    _______________________________________________
    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"

  • Next message: Alexander Leidinger: "Re: Patches to compile the kernel with Intel's C/C++ compiler"

    Relevant Pages

    • Re: newfs and mount vs. half-baked disks
      ... FFS requires its fragment size be no smaller than the sector size ... actually the fragment size in this context. ... a 60GB disk, but 16K/16K and 32K/any are significantly slower. ...
      (freebsd-arch)
    • UFS1 filesystem compatibility problem under Linux
      ... filesystems under Linux, but this failed. ... time to see why it failed, but I've since downloaded recent kernel ... filesystem blocksize was limited to a small selection of values, ... made regular use of fragment sizes up to and including the block ...
      (Linux-Kernel)
    • Re: Root FS corruption
      ... A subsequent reboot is needed for the ... A fragment ... allows for allocating a new block to the small file, ... Store the nextboot info "not in a filesystem". ...
      (freebsd-current)
    • Re: file fragmentation project
      ... > randomly fragment x% of files on a NTFS filesystem into y number of ... algorithm to fragment a file m bytes long into n pieces is: ... Write the file to be fragmented, and hope that the filesystem naively ... Kirk Strauser ...
      (comp.lang.python)
    • Re: [PATCH 8/8] vm: Add an tuning knob for vm.max_writeback_mb
      ... Writepage is called on byte 0, and now the filesystem gets to decide how ... ext4 is doing). ... We may fragment the file or we may fragment the ... Which is another way of saying, we *know* the page writeback routines ...
      (Linux-Kernel)