Steve Lord [lord@xxxxxxx] wrote:
> > Hi
> >
> > I have 2 questions about fsr.
> >
> > 1. Lilo is working on xfs (a least kernel images).
> > Is there a way to prevent relocation of lilo files (kernel images, etc.) by
> > fsr? I think this is _really_ nessesary.
>
> This is a good point, at the moment I would say that not running fsr on the
> root/boot filesystem is a good idea. In fact, there are only certain
> modes of operation which are going to create filesystems which need
> defragmentation - and in general the system disks such as / /usr and /boot
> will be fairly static in content and will not in general be in need of
> any form of defragmentation.
There should be a warning at the front of the xfs_fsr manpage and in the
FAQ. xfs_fsr is there and people will use it (or playing with it). And the
default of xfs_fsr is to reorganize all filesystems including /, /boot/.
Ok, it's not easy to produce a fragmented kernel image sized file on xfs. So
the risk is very low. But it is possible and loosing you ability to boot is
a very very bad thing.
Just an idea:
What's about using a extended attribute which signaling fsr
not to touch a file? lilo could write it to the files.
Remark: an ioctl (REISERFS_IOC_UNPACK) was added to lilo to unpack (untail)
files on reiserfs.
I thing a filesystemtype indepentent way to mark files not to relocated
would be great. In future this problem will get more important. IBM's jfs
has a defragmenter, perhaps reiserfs will got one and other new filesystems.
Maybe in future xfs_fsr will do more tricky reorganize files that just minimize
the
extends.
utz
|