why does sync() write an ext2 disk, even if no activity?
 

Hello,

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?


Yours,

Adrian, Cambridge, UK.

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.

Hope this helps some.

Yes, I know the intended behaviour of sync.

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.

Anybody want to chip in with an explanation?

There is a note about spindown at http://code.google.com/p/spindown/:
Might be worth a look-see?

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.

Thanks for the pointers, syg00.

There merely confirm that sync is writing to the disk, when it is not expected.

Mount shows my disk:
/dev/sdc2 on /mnt/temp type ext2 (rw,noatime,nodiratime,seclabel,errors=continue)

ls -al /mnt/temp:
drwxr-xr-x. 3 root root 4096 Jun 10 07:20 .
drwxr-xr-x. 10 root root 4096 Jun 10 07:21 ..
drwx------. 2 root root 16384 Jun 10 07:20 lost+found

[root@shed1 ~]# lsof | grep temp
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/adrians/.gvfs
Output information may be incomplete.

[root@shed1 .unison]# blktrace -d /dev/sdc2 -o - | blkparse -i -

I type "sync" in another terminal and see:

8,32 0 1 0.000000000 29727 A W 401625 + 8 <- (8,34) 0
8,34 0 2 0.000001230 29727 Q W 401625 + 8 [sync]
8,34 0 3 0.000005048 29727 G W 401625 + 8 [sync]
8,34 0 4 0.000005952 29727 P N [sync]
8,34 0 5 0.000006736 29727 I W 401625 + 8 [sync]

node 8,32 is /dev/sdc2, so this is interpreted as a write to sdc2, which is remapped to sdc.
401625 is the first sector of the partition.

I used dumpe2fs to display the filesystem superblock info:
I did two of these separating a sync. Sure enough, the "Last write time" field is being updated.
This looks like an "atime" update, except the device is mounted with noatime (see above).

Any more suggestions?

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).

KDE / Gnome does not appear to be the cuprit.

I repeated this in init 3 state, and got the same result.

Best Regards,

Adrian

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.