On Fri, 7 Mar 2003, Bogdan Costescu wrote:
> On 6 Mar 2003, Eric Sandeen wrote:
> > Hm, I suppose that for the truly paranoid, with cheap IDE disks,
> No, not only for them. The frequent access exists for all drives and
> will destroy a high-end SCSI disk just as well, but maybe not as fast.
I think it's important to remember that XFS has been in use for -many-
years on irix, on everything from personal desktops to huge servers
with filesystems on the order of tens of terabytes. While I'm
sure that usage patterns will affect the life of any device, I don't think
that this has been a problem in general.
(And, I can think of other disk usages patterns which could result in
disproportional use of one area of a disk - /var/log partitions, for
> Ehh, how about those using XFS on file servers that have to have an uptime
> of hundreds of days ? Changing its place online would be bliss...
Actually if this were implemented, a quick xfs_freeze/log move/xfs_thaw
would be plausible.
> However, placing the journal seems to raise the problem: where ? As it's
> accessed often, it should be on the area of the disk where speed is
> maximum (speed = read+write+seek). But if it's moved, can the new location
> be controlled somehow so that it doesn't accidentally end up in an area
> with low speed ? Of course, that does mean that free space has to exist at
> the new location. That begs the question: could defragmentation or
> something similar take care of creating free space at a specific location
> on disk ?
I think you're asking too much here... I think each individual disk would
need to be profiled to even know where the "fast" spots are. And then
technically, the log could go anywhere, but I think that for the effort
involved, the returns would not be that great.