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

adrian_stephens · 06-10-2011, 01:29 AM

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.

tronayne · 06-11-2011, 08:57 AM

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.

adrian_stephens · 06-11-2011, 12:42 PM

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?

tronayne · 06-11-2011, 01:31 PM

There is a note about spindown at http://code.google.com/p/spindown/:

Quote:

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.

Might be worth a look-see?

syg00 · 06-11-2011, 07:01 PM

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.

adrian_stephens · 06-12-2011, 01:25 AM

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:

Code:

[root@shed1 dev]# dumpe2fs -h /dev/sdc2
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          aa2936dd-1c47-410b-bb77-d90e97927745
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1615680
Block count:              6462146
Reserved block count:     323107
Free blocks:              6349489
Free inodes:              1615669
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1022
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8160
Inode blocks per group:   510
Filesystem created:       Fri Jun 10 07:20:20 2011
Last mount time:          n/a
Last write time:          Sun Jun 12 07:19:10 2011
Mount count:              2
Maximum mount count:      23
Last checked:             Fri Jun 10 07:20:20 2011
Check interval:           15552000 (6 months)
Next check after:         Wed Dec  7 06:20:20 2011
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      e58490c0-c6b7-4beb-bd94-91b6fe96787b

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?

selfprogrammed · 06-14-2011, 03:58 PM

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

adrian_stephens · 06-15-2011, 04:40 AM

KDE / Gnome does not appear to be the cuprit.

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

Best Regards,

Adrian

Skaperen · 06-15-2011, 03:28 PM

Quote:

Originally Posted by adrian_stephens

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.

selfprogrammed · 06-17-2011, 02:52 PM

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.