On 20101223_142848, Bob Proulx wrote: > Hi Paul, (offlist) > > I am making this offlist because my comments about this problem are > off topic for the coreutils list. > > > > I have been noticing that the ext4 w/ fsync fiasco is making > > > everything very much slower while saying that it is trying to make > > > things faster. The irony is tragic. I don't know if that is what you > > > are suffering from but it is potentially possible. > > > > Actually, I don't use ext4. I still using ext3. A few months ago I thought > > I had a problem with ext3, but the symptoms disappeared while trying to > > document it, about the time I throw away a bad disk. My guess is that > > that disk was corrupting something that made other disk also appear to > > be bad. But I didn't dig it out of the trash to pursue that theory. > > The problem will affect you no matter what filesystem you currently > use. Here is my summary of the problem. There is a high profile > kernel developer working for Google. He takes on ext4 as a project. > He decided that if he changed the order of execution of file > operations he could make his part of the world faster and make ext4 > appear faster. But doing so broke many, many, many applications that > rely upon the specified order. He then claimed that all of the rest > of the programmers in the world were bad programmers. We were all bad > programmers for using filesystem buffer cache. He claimed the only > correct way to program was to disable the buffer cache and to operate > at disk drive speeds. This has been done in most programs by calling > fsync(). On ext3 fsync() is unfortunately implemented by sync() which > flushes the entire cache. > > This problem was really noticed strongly by some other kernel > developers while compiling the kernel. A compile normallly took 20 > minutes to complete on an otherwise idle machine. Being a long time > waiting the developer would routinely surf the web with firefox. But > if they did then the compile would take 40 minutes. Firefox has > installed those fsync calls on every mouse click as they had been > instructed to to do by high profile kernel developers. That flushed > the cache with every mouse click and cost a large amount of > performance by running at disk drive speeds. > > In effect the kernel was changed with the advertisement that it would > make the filesystem faster but with the result that the system is now > very much slower than before. A Pyric victory. Many more of those > and it will be faster to go back to pencil and paper. > > Also he claimed that this was needed laptops. But this change > severely hurts laptops since the disk drive is never idle now and > can't spin down and therefore consumes more battery. So laptop users > are looking for a way to disable this in laptop mode. Again, a change > that was advertised to help laptop users is actively hurting laptop > users. > > Search the web. You will find a *lot* of discussion about this > topic. And it isn't over yet. > > Bob
1> I don't use ext4. How can that be my problem? 2> I DO use ssh to get into the host on which I am seeing the problem. I could try on one of my three other Squeeze boxes, but none of them have a /dev/sde1 so someone might think I'm fudging the data. Original suggested diagnostic seems not to conform to man page use of -e, but I've never used strace before and may misunderstand. To run it I just copy and paste between xterms in Gnome GUI. The simplified string, strace -o /tmp/df.strace.out df /dev/sde1 gives output that seems garbled when view using less and/or cat. I will not post it for fear of breakage. Did you read my last letter? What do you think of the idea of just doing the divide and round inside df? Your comment about a certain kernel developer confirms my impression that raising issues as to the correctness of kernel code can be VERY counter-productive. Better to ignore output that one doesn't find useful, and produce, from more basic data, output that is more to ones liking. As I mentioned this is already being done with certain time-stamps by coreutils developers. Cheers, -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
