| 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
| ||
|
Message-id: <20090720211831.GV4231@webber.adilger.int> Date: Mon, 20 Jul 2009 15:18:31 -0600 From: Andreas Dilger <adilger@....com> To: Ron Johnson <ron.l.johnson@....net> Cc: linux-ext4@...r.kernel.org Subject: Re: file allocation problem On Jul 19, 2009 17:45 -0500, Ron Johnson wrote: > On 2009-07-17 16:14, Andreas Dilger wrote: >> Well, this isn't quite correct. The mballoc code only tries to allocate >> "large" files on power-of-two boundaries, where large is 64kB by default, >> but is tunable in /proc. For smaller files it tries to pack them together >> into the same block, or into gaps that are exactly the size of the file. > > How does ext4 act on growing files? I.e., creating a tarball that, > obviously, starts at 0 bytes and then grows to multi-GB? ext4 has "delayed allocation" (delalloc) so that no blocks are allocated during initial file writes, but rather only when RAM is running short or when the data has been sitting around for a while. Normally, if you are writing to a file with _most_ applications the IO rate is high enough that within the 5-30s memory flush interval the size of the file has grown large enough to give the allocator an idea whether the file will be small or large. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- 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
Powered by blists - more mailing lists