linux-ext4 - Block estimates for delayed allocation in ext4 wrong?

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>] [day] [month] [year] [list]

Message-ID: <20090519165310.GE28289@duck.suse.cz>
Date:	Tue, 19 May 2009 18:53:10 +0200
From:	Jan Kara <jack@...e.cz>
To:	linux-ext4@...r.kernel.org
Subject: Block estimates for delayed allocation in ext4 wrong?

  Hi,

  I was looking into doing delayed allocation for ext3 in page_mkwrite()
and I've noticed that the way how ext4 estimates number of blocks it needs
to reserve during delayed allocation is probably wrong when inode uses
indirect blocks and not extents. The problem is with files with holes - for
example we write blocks 1024, 2048, 3072, 4096, we have to allocate
indirect block together with each data block we write. Therefore we need
at least 8 blocks reserved but ext4_indirect_calc_metadata_amount()
will reserve only 6 of them.
  We can only improve the estimate against the worst case (allocating all
indirect blocks) if we know some block before the one for which we estimate
needed amount is already allocated / has space reserved. But that's kind of
non-trivial to detect. Maybe what we could do is look into pagecache, find
the first page before the current one, check that it has mapped or delayed
buffer and subtract indirect blocks for buffers in this page from those we
need to reserve. But the locking is going to be nasty :( (we need page lock
to safely investigate buffers in that page).
  Maybe counting with the worst case is better after all. What do you think?

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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