xfs
[Top] [All Lists]

Just some odd questions out of the blue...

To: <linux-xfs@xxxxxxxxxxx>
Subject: Just some odd questions out of the blue...
From: "l.a walsh" <xfs@xxxxxxxxx>
Date: Thu, 6 Mar 2003 17:42:28 -0800
Importance: Normal
Sender: linux-xfs-bounce@xxxxxxxxxxx
I was reading a bit through the messages about high activity in
the log file area of the disk.  Seems like ...well...that's
likely going to up the #seeks needed for writes, right?

So lets say you had 2 disks...would it make sense to put the log
of disk1 on disk2 and the log of disk2 on disk1?  This would be
under the assumption, that most often, you will be writing to 1 of
the two disks (RAID stuff excluded from this meandering).

Seems like if 90% of the time you are going to be writing to only
1 disk at a time, it could really eliminate excessive seekage and
theoretically up throughput.

Second question ... suppose one disk was faster than the other --
or one was a sda and the other hda.  How much metadata is written
compared to file data, i.e. is there some average ratio or range?

On the assumption that metadata is smaller, seem like one could use
a slower log disk for a primary work disk, and the slower log disk
is mostly archival things that aren't written alot, but more read
alot -- like mp3's, or CD images....things where the slower read isn't
going to be a big problem.

When writing to disks with a cache, does XFS force any flushes (like
on log data?)  Seem like even if you had a slower disk but an 8Mb
cache you could keep up with a fairly good write speed on the faster
disk.

Dunno....

But here's another Q...if you don't flush the on disk cache after
a log write, then it is 'granted' that the potential for metadata
loss is at least the size of the on-disk cache.  That could beg
the question -- would it be of any benefit to write a pseudo-block
device that lives on top of a disk that just does read-write
caching -- maybe it lives with a 64Mb Buffer and attempts to use
geometry knowledge of the disk to optimize head motion, whatever.
But the point there, being, you could lose 64Mb of log data if
the write-log function doesn't flush.

If it does flush..well, that would eliminate much of the benefit
of an off-disk pseudo device as well as the on-disk cache....some
how that seems unfortunate.  Maybe this is a 'tuneable'
--write-log=sync/async?

sorry for the meandering...just bouncing around ideas....

-linda





<Prev in Thread] Current Thread [Next in Thread>