linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: linux-ext4@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org, npiggin@suse.de
Subject: [PATCH 0/4] Make page_mkwrite() more useful for blocksize < pagesize
Date: Wed, 29 Apr 2009 12:02:46 +0200	[thread overview]
Message-ID: <1240999370-27502-1-git-send-email-jack@suse.cz> (raw)

  Hi,

  this is a next version of my patches which implement VFS helpers so that
page_mkwrite() is reliably called at the first write access to a page after
the amount of blocks allocated under the page could change. This solves
the problem with filesystems dropping data on the floor when they hit ENOSPC
(or EDQUOT) during writepage().
  The series also contains patches for ext[2-4] showing how the VFS framework
can be used. This is probably not the final version of the patches since I did
some performance measurements with ext3 and allocating blocks on page-fault
time instead of at writepage() time has a significant cost - BerkelyDB based
workloads are slower by ~10% because of much higher file fragmentation
(essentially allocation at writepage time had a kind of delayed allocation
effect for us and it helped a lot in these random write scenarios). I'm
thinking how to solve this so that any filesystem wanting reliable mmap
and reasonable performance behaviour doesn't have to implement something like
delayed allocation or other workaround again...

									Honza

             reply	other threads:[~2009-04-29 10:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-29 10:02 Jan Kara [this message]
2009-04-29 10:02 ` [PATCH 1/4] vfs: Add better VFS support for page_mkwrite when blocksize < pagesize Jan Kara
2009-04-29 10:02 ` [PATCH 2/4] ext2: Allocate space for mmaped file on page fault Jan Kara
2009-04-29 10:02 ` [PATCH 3/4] ext4: Make sure blocks are properly allocated under mmaped page even when blocksize < pagesize Jan Kara
2009-04-29 10:02 ` [PATCH 4/4] ext3: Allocate space for mmaped file on page fault Jan Kara

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=1240999370-27502-1-git-send-email-jack@suse.cz \
    --to=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=npiggin@suse.de \
    /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;
as well as URLs for NNTP newsgroup(s).