Re: Default FS block size

> Lelik Bolik wrote:
>  > Thanks Phillip for the reply.
>  > But I didn't mean compression block size, I meant block layer block size.
>  > This size is used to request data from block layer.
>  > To make my question more clear, I attached patch, which I used for tests.
>  >
>
>
> > -       msblk->devblksize = sb_min_blocksize(s, BLOCK_SIZE);
>  > +//     msblk->devblksize = sb_min_blocksize(s, BLOCK_SIZE);
>
>
>  For the benefit of other readers this sets the underlying buffer cache
>  I/O to be the minimum of 1K (BLOCK_SIZE) or the smallest block size
>  supported by the block device (between 1K and 4K).
>
>  Your question now makes more sense.
>
>  As you may be aware Squashfs filesystem blocks are not aligned on sector
>  boundaries but on byte boundaries to maximise compresssion.  What this
>  means is that when reading a Squashfs block in units of the above buffer
>  cache size it will invariably involve a partial read of the first buffer
>  cache block and a partial read of the last buffer cache block.  The
>  smaller the buffer cache I/O block the less wasted I/O is performed.
>  For instance a Squashfs block overlapping 60 bytes into the last buffer
>  cache block @ 1K I/O size results in less wasted I/O than @ 4K I/O size.
>
>  Squashfs queues the buffer I/O requests in one operation, and assuming a
>  correctly working elevator algorithm, consecutive 1K buffer cache reads
>  should perform identically to consecutive 4K buffer cache reads.  This
>  is especially true with 'modern' intelligent disks and I/O controllers
>  with large readahead buffers which optimise for sequential access.
>
>  So given my previous comment that smaller buffer cache block size
>  results in less I/O performed by Squashfs, I'm therefore surprised you
>  find a 7% boot time speed up moving from a 1K block size to a 4K block
>  size.  What block device did you do your tests on?  From you question
>  I'm assuming it is a flash device (is it NOR or NAND?) via the MTD block
>  layer?
>
>  I can only assume your flash driver (or the MTD stack) has a high access
>  latency per block access which is incurred even when block accesses are
>  consecutive.  Incidentally elevator algorithms have little effect on
>  flash access performance because seek time between blocks on flash is
>  negligible.
>
>  I will do some tests on other block devices to check their behaviour
>  when I have time.  Thanks for bringing this to my attention.
>
>  Phillip
>
>
>
>
>  > On Tue, Feb 12, 2008 at 9:54 AM, Phillip Lougher
>  > <phillip@...> wrote:
>  >> Lelik Bolik wrote:
>  >>  > Dear all.
>  >>  > By default Linux kernel uses 1k FS block size.
>  >>  > AFAIK, Squash FS is mainly used on embededded system with 4k page size
>  >>  > and flash memory. And almost all VFS operation are made on whole
>  >>  > pages.
>  >>  > Increasing FS block size from 1k to 4k could speed up read accesses
>  >>  > and reduce elevator overhead. It should reduce system boot-up time.
>  >>  > I've made several tests and they show up to 7% booting time reduction.
>  >>  > Could You explain, why 1k was chosen as a default FS block size?
>  >>  >
>  >>
>  >>  This shows some confusion.
>  >>
>  >>  Linux I/O is conceptually split into two layers the block cache and the
>  >>  page cache.  Buffers in the block cache are of the underlying block
>  >>  device's sector size which is normally 512 bytes.  Page cache buffers
>  >>  are normally 4K (the page size).
>  >>
>  >>  A filesystem is free to use any block size, which doesn't have to be
>  >>  either the underlying block device sector size or the page size.
>  >>  However, most often Linux filesystems have 4K block sizes matching the
>  >>  page size.
>  >>
>  >>  Irrespective of the filesystem block size and the sector size, Linux
>  >>  (the VFS layer) performs I/O on the filesystem in page size units or 4K.
>  >>   For a given 4K I/O request it is the responsibility of the filesystem
>  >>  to map that to one of its (possibly different size) blocks, which in
>  >>  turn it maps down to a series of sector size I/O requests to the
>  >>  underlying block device.
>  >>
>  >>  Prior to version 2.0 Squashfs used 32K blocks, which meant for a given
>  >>  4K VFS request it read 32K of data, and pushed the remaining 28K into
>  >>  the page cache itself.  Squashfs from 2.0 to 3.2 used 64K blocks, and
>  >>  the latest 3.3 version uses by default 128K blocks.
>  >>
>  >>  So to directly answer your question, Squashfs doesn't use 1K blocks, it
>  >>  already uses 128K blocks.
>  >>
>  >>  Phillip
>  >>
>  >
>  > -------------------------------------------------------------------------
>  > This SF.net email is sponsored by: Microsoft
>  > Defy all challenges. Microsoft(R) Visual Studio 2008.
>  > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  > _______________________________________________
>  > Squashfs-devel mailing list
>  > Squashfs-devel@...
>  > https://lists.sourceforge.net/lists/listinfo/squashfs-devel
>  >
>
>