public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Problem with delayed allocation
Date: Tue, 5 Aug 2008 11:16:02 -0400	[thread overview]
Message-ID: <20080805151602.GC12544@mit.edu> (raw)
In-Reply-To: <20080805142403.GA16529@skywalker>

On Tue, Aug 05, 2008 at 07:54:03PM +0530, Aneesh Kumar K.V wrote:
> But we would still can have pages skipped in the second call to
> ext4_da_writepages(). But this make me wonder how xfs is doing
> delalloc. 

I just checked XFS, and it does the right thing.  See below for my
tests.  The two interesting things of note is that XFS takes a lot
longer (5 seconds vs 0.293 seconds) to do the unmount, so they are
definitely doing something right to wait for the dellayed allocations
to get mapped and written to disk.  The second thing of note is that
ext4 is currently beating XFS at the totally meaningless reiser4
benchmark (aka untar a kernel source tree :-), which we can do in 28
seconds versus XFS's 31 seconds.

So for this test, we're 12% faster (20% faster if we include the time
taken by the remount read-only step), but we're losing 9% of the data.  :-/

		  	     	   	     - Ted


<tytso.root@closure> {/}, level 2  
270# /sbin/mkfs.xfs -f /dev/thunk/testbench; mount /dev/thunk/testbench /mnt; cd /mnt; time tar xjf /usr/projects/linux/linux-2.6.26-3495-gf303489.tar.bz2 ; time mount -o remount,ro /mnt; cd ..; du -s /mnt; umount /mnt; mount /dev/thunk/testbench /mnt; du -s /mnt; umount /mnt
meta-data=/dev/thunk/testbench   isize=256    agcount=8, agsize=163840 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=1310720, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0

real	 0m31.060s
user	 0m19.965s
sys	 0m8.323s

real	 0m5.263s
user	 0m0.000s
sys	 0m0.847s
320872	 /mnt
320872	 /mnt
<tytso.root@closure> {/}, level 2  
271# /sbin/mkfs.ext4dev  /dev/thunk/testbench; mount /dev/thunk/testbench /mnt; cd /mnt; time tar xjf /usr/projects/linux/linux-2.6.26-3495-gf303489.tar.bz2 ; time mount -o remount,ro /mnt; cd ..; du -s /mnt; umount /mnt; mount /dev/thunk/testbench /mnt; du -s /mnt; umount /mnt
mke2fs 1.41.0 (10-Jul-2008)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
327680 inodes, 1310720 blocks
65536 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1342177280
40 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
	   32768, 98304, 163840, 229376, 294912, 819200, 884736

Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 32 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

real	  0m28.125s
user	  0m18.545s
sys	  0m8.983s

real	  0m0.293s
user	  0m0.000s
sys	  0m0.093s
323736	  /mnt
284332	  /mnt

  reply	other threads:[~2008-08-05 15:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-02 20:07 Problem with delayed allocation Theodore Ts'o
2008-08-02 22:40 ` Theodore Tso
2008-08-04  3:16 ` Aneesh Kumar K.V
2008-08-04 14:08   ` Theodore Tso
2008-08-04 14:52 ` Aneesh Kumar K.V
2008-08-04 15:27   ` Aneesh Kumar K.V
2008-08-04 15:33     ` Aneesh Kumar K.V
2008-08-04 16:35 ` Aneesh Kumar K.V
2008-08-05  6:44   ` Theodore Tso
2008-08-05  6:52     ` Aneesh Kumar K.V
2008-08-05 13:21       ` Aneesh Kumar K.V
2008-08-05 13:47         ` Theodore Tso
2008-08-05 14:24           ` Aneesh Kumar K.V
2008-08-05 15:16             ` Theodore Tso [this message]
2008-08-06 10:05         ` Aneesh Kumar K.V
2008-08-06 10:11           ` Aneesh Kumar K.V
2008-08-07  0:49             ` Mingming Cao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080805151602.GC12544@mit.edu \
    --to=tytso@mit.edu \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox