On Sun, Nov 11, 2007 at 09:46:43PM -0800, Christopher Layne <[EMAIL PROTECTED]> wrote: > > Most unix systems cache data for quite long, butwhen they write, usually > > user mode apps also halt. For throughput this is of little concern, but > > in a game server I wrote, even an fsync could freeze the server for 15-20 > > seconds(!) when another sync was in progress at the same time, or when > > some othe rprogram geenrated lots of I/O (for example a backup/restore). > > BTW: This isn't a global Linux issue, it's specifically an issue with ext3 > and the > way it handles fsync() on a global scale.
I am specifically not using ext3 anywhere on any of my systems, so, no, this has nothing whatsoever to do with ext3 and its many deficencies. > http://kerneltrap.org/node/14148 > > Personally, I use XFS (awesome design). Yeah, and even slower than ext3. By far. And this issue happens with xfs just the same. When memory grows tight and linux needs to flush, the system more or less freezes (w.r.t. I/O). I even see operations such as utime() freeze, even when everything is in the cache. (Ok, XFS is in fact the fastest filesystem when all you want to do is stream very large files, it can be very space-efficient, but at *anything* else it rather sucks, speed-wise). (And it fragments like hell, but at least it has an online defragmenter, which helps those very large files stream even faster). :) -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
