Timothy Shimmin <tes@xxxxxxx> writes:
> Thor Kristoffersen wrote:
>>> Use blktrace, or echo 1 > /proc/sys/vm/block_dump to see what block and
>>> who's writing it... it's probably the superblock? what kernel?
>>
>> This is kernel version 2.6.24. More specifically it's a Debian kernel from
>> package linux-image-2.6.24-1-686 (2.6.24-4).
>>
>> I put the system in runlevel 1 and executed the test as you suggested. On
>> /dev/sda3 I have mounted (with noatime) an XFS filesystem that contains
>> data that is not supposed to be accessed by any process. In the output
>> below I have filtered out all accesses to other partitions. (BTW, this is
>> not actually the disk that I wanted to spin down, but I think the log
>> proves my point.)
>>
>>
> I'm wondering if that is writing to the xfs ondisk log/journal in those cases.
> What does 'xfs_logprint -t' show in these "idle" states
> after these writes?
xfs_logprint produces output like the one shown below, so it does indeed
look like it's writing to the journal. But why should it need to keep
writing to the journal when there have been no updates to any files on that
partition recently?
Thor
----------------------------------------------------------------
xfs_logprint:
data device: 0x803
log device: 0x803 daddr: 682818768 length: 262144
log tail: 157103 head: 157107 state: <DIRTY>
LOG REC AT LSN cycle 1 block 157103 (0x1, 0x265af)
============================================================================
TRANS: tid:0xf2fcd6e0 type:SB_COUNT #items:1 trans:0x0 q:0x80b4c08
BUF: cnt:2 total:2 a:0x8099140 len:24 a:0x80ac748 len:128
BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0
SUPER Block Buffer:
LOG REC AT LSN cycle 1 block 157105 (0x1, 0x265b1)
============================================================================
TRANS: tid:0xf2fcd790 type:SB_COUNT #items:1 trans:0x0 q:0x80b4c08
BUF: cnt:2 total:2 a:0x8099140 len:24 a:0x80ac748 len:128
BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0
SUPER Block Buffer:
|