I'm trying to tune a linux system to spin down its (ext2-formatted) disk when
the system is idle. I've worked down to two problematic applications that
periodically spin up the disk, even though the (tiny) file they're writing is
(allegedly) on a tmpfs partition (/tmp/application/datafile, as it happens).
Enabling the vm debugging gets me output like:
kjournald(303): WRITE block 151824 on hda1
kjournald(303): WRITE block 151832 on hda1
kjournald(303): WRITE block 151840 on hda1
kjournald(303): WRITE block 151848 on hda1
kjournald(303): WRITE block 151856 on hda1
kjournald(303): WRITE block 151864 on hda1
pdflush(135): WRITE block 258211840 on hda1
pdflush(135): WRITE block 258211848 on hda1
pdflush(135): WRITE block 258211856 on hda1
pdflush(135): WRITE block 258310144 on hda1
pdflush(135): WRITE block 0 on hda1
pdflush(135): WRITE block 16 on hda1
pdflush(135): WRITE block 64 on hda1
pdflush(135): WRITE block 56098816 on hda1
pdflush(135): WRITE block 56100968 on hda1
pdflush(135): WRITE block 61079552 on hda1
(hda1 is an ext2-formatted partition, mounted noatime)
Is there any way to work back from block to inode to (hopefully) location in the
directory structure this is happening? For some reason, I don't get app and file
name (like I do with other programes), just some blocks that the disk got spun
up to write.
My appologies if there's a well-known tool for doing this; the furthest down
I've been able to dig is the inode level.
On Friday 29 September 2006 06:47, Dave Edwards wrote:
> ...
> Is there any way to work back from block to inode to (hopefully) location
> in the directory structure this is happening? For some reason, I don't get
from man debugfs:
icheck block ...
Print a listing of the inodes which use the one or more blocks
specified on the command line.
/Peter
> app and file name (like I do with other programes), just some blocks that
> the disk got spun up to write.
>
> My appologies if there's a well-known tool for doing this; the furthest
> down I've been able to dig is the inode level.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 29, 2006 at 04:47:38AM +0000, Dave Edwards wrote:
> I'm trying to tune a linux system to spin down its (ext2-formatted) disk when
> the system is idle. I've worked down to two problematic applications that
> periodically spin up the disk, even though the (tiny) file they're writing is
> (allegedly) on a tmpfs partition (/tmp/application/datafile, as it happens).
If you are using a distribution that has SystemTap preinstalled,
something that may be simpler to use would be a SystemTap script which
logs which process id's are calling the write system call. Yes,
you'll get false negatives for processes writing to pty's and serial
devices, et. al. If you only have ext3 filesystems on your system,
you can could modify the SystemTap script to print a message including
the pid each time there is a call to ext3_file_write().
(With more advanced SystemTap-foo it would be possible to extract out
the inode information and print the inode #, but you'd have to contact
a SystemTap user's mailing list for help doing something like that.
Still, I suspect getting the process ID is hopefully enough for your
purposes.)
Regards,
- Ted
On Sep 29, 2006 04:47 +0000, Dave Edwards wrote:
> I'm trying to tune a linux system to spin down its (ext2-formatted) disk when
> the system is idle. I've worked down to two problematic applications that
> periodically spin up the disk, even though the (tiny) file they're writing is
> (allegedly) on a tmpfs partition (/tmp/application/datafile, as it happens).
> Enabling the vm debugging gets me output like:
>
> kjournald(303): WRITE block 151824 on hda1
> kjournald(303): WRITE block 151832 on hda1
> kjournald(303): WRITE block 151840 on hda1
> kjournald(303): WRITE block 151848 on hda1
> kjournald(303): WRITE block 151856 on hda1
> kjournald(303): WRITE block 151864 on hda1
This is ext3 (journal thread) not ext2.
> pdflush(135): WRITE block 258211840 on hda1
> pdflush(135): WRITE block 258211848 on hda1
> pdflush(135): WRITE block 258211856 on hda1
> pdflush(135): WRITE block 258310144 on hda1
> pdflush(135): WRITE block 0 on hda1
> pdflush(135): WRITE block 16 on hda1
> pdflush(135): WRITE block 64 on hda1
> pdflush(135): WRITE block 56098816 on hda1
> pdflush(135): WRITE block 56100968 on hda1
> pdflush(135): WRITE block 61079552 on hda1
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.