linux-ext4 - [PATCH 0/4] Make page_mkwrite() more useful for blocksize

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1240999370-27502-1-git-send-email-jack@suse.cz>
Date:	Wed, 29 Apr 2009 12:02:46 +0200
From:	Jan Kara <jack@...e.cz>
To:	linux-ext4@...r.kernel.org
Cc:	linux-fsdevel@...r.kernel.org, npiggin@...e.de
Subject: [PATCH 0/4] Make page_mkwrite() more useful for blocksize < pagesize

  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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html