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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
