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. - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
