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 ca

Re: [PATCH] provide missing mode for open-create in check_mntent_file

On Aug 16, 2007 17:37 -0500, Eric Sandeen wrote: > F8 is catching opens with O_CREAT flags and no mode now, and refusing > to build them... Yay, we had bugs-o-plenty in Lustre because of this being done in apps. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems,

Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)

On Fri, 17 Aug 2007 12:36:32 +0400 Alex Tomas <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > Sort-of. But the per-superpblock, per-inode writeback code is pretty > > careful to avoid livelocks. The per-inode writeback is a strict single > > linear sweep across the file. It'll basically w

Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)

Andrew Morton wrote: Sort-of. But the per-superpblock, per-inode writeback code is pretty careful to avoid livelocks. The per-inode writeback is a strict single linear sweep across the file. It'll basically write out anything which was dirty when it was called. The per-superblock inode walk i