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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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