Hello Stan,
On Thu, Dec 23, 2010 at 06:54:19PM -0600, Stan Hoeppner wrote:
> Petre Rodan put forth on 12/23/2010 3:16 PM:
>
> > but my original mail had a different target really. I have to recognize
> > that I don't know much about the inner-workings of a filesystem, but I find
> > it odd that once there is no input from the outside, a process keeps
> > writing to the drive indefinitely. in my very narrow thinking the fact that
> > these writes dissapear after a remount would prove their redundance.
>
> Ahh, quite right. Sorry Petre. This might shed some light on your
> issue. Old background thread:
>
> http://oss.sgi.com/archives/xfs/2003-09/msg00674.html
>
> Current documentation on this turnable knob:
>
> http://www.mjmwired.net/kernel/Documentation/filesystems/xfs.txt
I appreciate your quick replies, but rest assured that I did search the
archives and the documentation that came with the kernel.
I would be delighted to know the underlying reason why internal xfs processes
need to flush things to the drive more than once. can't it be as easy as
accept write command -> cache -> actual write to the hardware -> clean
cache/log/dirty metadata -> sleep until next command comes (and not touch the
drive in any way until then)
what am I missing in this picture? if anything needs to be flushed, why do it
over and over again, once is not enough ?
what I found (see first mail from thread) is that a write to an xfs partition
triggers an xfssyncd process to continually write to the drive for no apparent
reason. and keeps writing at regulated intervals long after any other read or
write request has been made from the outside. I left the drive untouched for 12
hours and xfssyncd was still pinging the drive. and there is no xfssyncd
process pinging if I do not do initiate a write to the disk after the partition
is mounted, so to me that means that xfs would function without constant
writing to the underlying device.
> fs.xfs.xfssyncd_centisecs (Min: 100 Default: 3000 Max: 720000)
> fs.xfs.age_buffer_centisecs (Min: 100 Default: 1500 Max: 720000)
just increasing the delay until an inevitable and seemingly redundant disk
write is not what I want.
I was searching for an option to make internal xfs processes not touch the
drive after the buffers/log/dirty metadata have been flushed (once).
thanks,
peter
|