| 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: Tue, 10 Oct 2006 11:55:12 +1000 From: David Chinner <dgc@....com> To: Steve Lord <lord@....org> Cc: linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org, xfs@....sgi.com Subject: Re: Directories > 2GB On Mon, Oct 09, 2006 at 04:53:02PM -0500, Steve Lord wrote: > You might want to think about keeping the directory a little > more contiguous than individual disk blocks. XFS does have > code in it to allocate the directory in chunks larger than > a single file system block. It does not get used on linux > because the code was written under the assumption you can > see the whole chunk as a single piece of memory which does not > work to well in the linux kernel. This code is enabled and seems to work in Linux. I don't know if it passes xfsqa so I don't know how reliable this feature is. TO check it all I did was run a quick test on a x86_64 kernel (4k page size) using 16k directory blocks (4 pages): # mkfs.xfs -f -n size=16384 /dev/ubd/1 ..... # xfs_db -r -c "sb 0" -c "p dirblklog" /dev/ubd/1 dirblklog = 2 # mount /dev/ubd/1 /mnt/xfs # for i in `seq 0 1 100000`; do touch fred.$i; done # umount /mnt/xfs # mount /mnt/xfs # ls /mnt/xfs |wc -l 100000 # rm -rf /mnt/xfs/* # ls /mnt/xfs |wc -l 0 # umount /mnt/xfs # Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists