| 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: <5286EF78-DE5C-4B3F-ACE9-EFA2CBB535EF@dilger.ca> Date: Sat, 18 Jun 2011 13:44:28 -0600 From: Andreas Dilger <adilger@...ger.ca> To: Stephan Boettcher <boettcher@...sik.uni-kiel.de> Cc: ext4 development <linux-ext4@...r.kernel.org> Subject: Re: 2.6.39.1: Intel I340-T4: irq/64-eth3-TxR: page allocation failure. order:1, mode:0x20 On 2011-06-18, at 11:39 AM, Stephan Boettcher wrote: > Andreas Dilger <adilger@...ger.ca> writes: >> There are a few places in the ext4 mount that are doing large >> allocations. In some places they fall back to vmalloc, so they should >> really be done with GFP_NOWARN. >> >> A few places don't yet fall back to vmalloc(), which is a problem >> with fragmented memory or very large filesystems. We were trying to >> test a 192TB ext4 filesystem, but were unable to mount it without >> patching the kernel. > > :-O ... my puny 20TB ext4 filesystem did not do something like > this, yet. What sort of experience do you have with using a filesystem > 20TB? I don't think there are many users out there yet that are doing this today, so it would be great if you could share some data with us. So far, we've only been doing testing and benchmarking (mke2fs, e2fsck times, IO and metadata load tests, etc) and I don't know that all of the "real world" corner cases have been tested yet. Cheers, Andreas -- 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