why does sync() write an ext2 disk, even if no activity?
Linux - DesktopThis forum is for the discussion of all Linux Software used in a desktop context.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
why does sync() write an ext2 disk, even if no activity?
I have fc15 32-bit. I want to spin down one of my hard disks using spindown. /dev/sdc1 is the only partion mounted from this disk, formatted ext2, mounted with noatime and nodiratime.
watch "cat /proc/diskstats | grep /dev/sdc1" to observe IO on the disk.
A command-line sync causes a bunch of sector operations each and every time.
Why? I want to spin the disk down. It's formatted ext2 so that there should be no kjournald involvement. No process has any files open on the disk, so sync should have nothing to write.
I'm trying to get spindown to work. It did on FC10 with the same disk configuration. So why won't it on FC15?
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
The sync utility "Force changed blocks to disk, update the super block" (from man sync.
Whenever you do a disk operation blocks are read from or written to the drive in chunks from buffers (memory). The size of the read or write varies by system -- my system, a 64-bit platform, has a BUFSIZ of 8192 (BUFSIZ is hardware dependent and is the default system I/O buffer size; the token, BUFSIZ, is a defined system variable). Your system may vary from that value but that's not really important and you don't want to mess with it anyway.
When you (or the system itself) sync, you're flushing the buffers to the hardware. The system does this periodically and always does it on shutdown; it's just making sure that everything is written to the disk.
You may notice, if you plug in a flash drive and write to it that the command you use to write with (say, cp), returns almost instantly but the LED on the flash drive flashes for quite some time -- that's the buffers being flushed. And if you do a cp to a flash drive and then immediately enter sync, the buffers are flushed all in one go (takes a while, that) and you won't get a prompt back for some time.
So, bottom line, that behavior is completely normal.
I'm trying to spin down disks. The writing to the disks on sync is a symptom (and an easy one to reproduce) that may explain why spindown writes to the disk whenever spindown status is displayed, or once per cycle.
There is nothing writing to the disks. lsof reports no open files.
Sync() writes buffers, but only if something has something to write. In this case, nothing does. So the writing of
anything (or reading for that matter) is unexpected.
It is sufficient to mount an empty ext2 filesystem to show this behaviour.
As I said, this doesn't happen under FC10, so something new is happening under FC>10.
The file-system is non-journalled (ext2), so the journal daemons should not be interested in the disk.
Users upgrading from v0.2.1 or older to v0.2.2 or newer need to update there configuration file. The command parameter in this version expects the command to execute to spindown the disk and not just the parameters for sg_start.
So, if your command parameter used to read "command = --stop" it should now read "command = sg_start --stop".
This has been done because some users had trouble spinning IDE disks down and had to use hdparm. I'm sorry for the inconvenience.
You don't need files open to write to a disk - you don't even need it mounted; mkfs for example.
And don't believe sync - it merely schedules the flush, doesn't actually do it. That's what bdi (nee pdflush) is there for.
Maybe have a look at blktrace if you really want to know what's (actually) hitting the disk - as in what sectors. Maybe iotop will tell you who.
I too have tried to track down the program that keeps accessing the drives.
Linux 2.4 did not do this, but something in Linux 2.6 keeps accessing the drives.
I suspect that something in KDE (they keep trying to imitate VISTA stuff, and I keep trying to disable it again) is doing automatic scanning of 'everything' looking for any changes.
This obsessive behavior completely overwhelms our attempts to manage our own computers.
Test with and without KDE (or xfce, etc) running.
Test with different mounting options, and unmounted. I think one mounting option does frequent syncs, to keep removable media updated, like it was on Win98 (where you could just yank them out anytime).
Last edited by selfprogrammed; 06-14-2011 at 04:03 PM.
I repeated this in init 3 state, and got the same result.
In the past, and maybe also the present, some programs in KDE/Gnome would scan for device state changes. Now days, udev is doing that, it seems. Perhaps it does so because some older devices had no way to push a notification of change to the CPU. Maybe there's a way to tell udev not to poll, and just listen.
May take extreme testing measures to even track it down.
Attempting to disable features in KDE, and disable kernel features (custom kernel compilation), until find it, will take massive amount of time.
Have similar problem with KDE/X-Windows messing up the video after an CTL-ALT-F1 switch to a console. Killing the KDE-plasma process was the only thing I could find that would stop it.
Never could discover what it needed to do to video registers so often.
The pity is that there is someone out there who programmed this and knows exactly what is happening.
Last edited by selfprogrammed; 06-17-2011 at 02:54 PM.