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, 17 Aug 2007 22:42:47 +0400 From: Alex Tomas <alex@...sterfs.com> To: Andrew Morton <akpm@...ux-foundation.org> CC: "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org> Subject: Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation) Andrew Morton wrote: >> OTOH, the faster we go through data sync part of commit, the better. given >> that lots of inodes can be dirty with no data to sync, it's going to take >> long in some cases. it's especially bad because commit doesn't scale to many >> CPUs. > > eh? I mean that number inodes to scan can be order of magnitude larger than number of inodes needing sync for this given transaction. commit thread has to scan them all (quite amount of CPU, i guess) and we can't use >1 CPU to speed the scan up. >> also, why would we need to flush *everything* every 5s? just because ext3 does >> this? sounds strange. if somebody really need this we could add this possibility >> to regular writeback path (making it tunable). but I'd rather prefer to have >> a separate (fast, lightweight, scalable) mechanism to support data=ordered. >> > > Yeah, that would make sense, perhaps. > > Or just speed the existing stuff up. iirc the main problem in there is unrelated > to data writeback. There are situations where the running transaction has to block > behind metadata writeout which the committing transaction is performing. I > reluctantly put that in years ago to get us out of a tight spot and it > never got optimised. AFAIU, existing writeback is built around dirty inodes list and dirty bit in per-inode radix tree. in order to avoid scanning too much (see before) we'd need a separate list and probably one more bit in radix tree. plus some code to allow writeback to use new list/tag. as for the main problem ... I'd very appreciate any details. probably it was about several blocks in page when one block is allocated in transaction 1 and next block is being allocated in transaction 2? thanks, Alex - 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