| 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
| ||
|
Date: Fri, 13 Oct 2006 02:10:02 -0600 From: Andreas Dilger <adilger@...sterfs.com> To: Theodore Ts'o <tytso@....edu> Cc: linux-ext4@...r.kernel.org, Alex Tomas <alex@...sterfs.com> Subject: Re: Design alternatives for fragments/file tail support in ext4 On Oct 11, 2006 09:55 -0400, Theodore Ts'o wrote: > Block allocation clusters > ========================= > The basic idea is that we store in the superblock the size of a block > allocation cluster, and that we change the allocation algorithm and the > preallocation code to always try to allocate blocks so that whenever > possible, an inode will use contiguous clusters of blocks, which are > aligned in multiples of the cluster size. As mentioned in the weekly conference call - Alex has already implemented this as part of the mballoc code that CFS uses in conjunction with extents. There is a /proc tunable for the cluster size, which currently defaults to 1MB clusters (the Lustre RPC size) to optimize performance for RAID systems. The allocations are aligned with the LUN so that an integer number of RAID stripes are modified for a write. Smaller allocation chunks are packed together. Alex is working to update the multi-block allocator for the 2.6.18 kernel, in conjunction with delayed allocation for ext4, and will hopefully have a patch soon. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, 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