On Tuesday 20 March 2007 19:21, HM wrote:
Kern Sibbald schrieb:
Filesystems do fragment if they are getting full. And there is no
real way around this.
XFS tries to avoid fragmentation of files by something that is
called "Delayed allocation" but XFS nevertheless ships a
defragmentation tool with its fs-utils. (I do not know such a tool
for ext2/3 btw)
I think what the original poster tried to say is:
Bacula could help in filesystems not getting too fragmented over
time by not freeing its space used, but instead just overwrite it.
If you want, you can force Bacula to run that way, but IMO it is very
dangerous.
Deleting then rewriting is more safe than overwriting? Is it dangerous
to overwrite tapes, then? Or should I use a big magnet before letting
bacule recycle it?
When Bacula is scanning, listing, or restoring (depending on the exact
options) from a volume, it will read to the end of the volume, so with your
scheme, such operations will fail.
This would definitly make much sense in some (if not all)
environments as it would keep filesystem performnace at a high
level.
I think this is a bad idea -- there are already many people who complain
that
Bacula does not release the space until it starts to rewrite the file, so
I
cannot see making the situation worse to try to resolve what I would call
an "end point" problem that can be eliminated by disk management
procedures.
This is the first argument I read. I do not understand the other
peoples reasons for complains like this. But bacula actually waits until
rewriting currently. So place is "wasted" (given that there were
arguments for considering the place as wasted) anyway, so why not just
omit the truncate and cope files just like tapes?
Because when a file is overwritten and not truncated, it ends at the original
size of the file, when a tape is overwritten, it ends at the end of the new
data.
And to be honest: This has nothing to do with a "strange OS that is
not state of the art" or you would call todays linux to be such an
OS.
Please think about it a second time...
I have thought about it a second time, and Bacula is a user program, it
shouldn't have to deal with disk fragmentation, which is for the OS or for
the user to manage.
Above you state, it is the user's way that fragment disks. Then you say,
bacula is a user program. So what is your point? Systems do fragment and
they will keep on doing this in future.
No, good systems such as Linux do not fragment the disk nor do programs such
as Bacula fragment the disk. The disk becomes fragmented only if there are
multiple processes writing the disk at the same time, or some files are
deleted. The administrator (I used the word user in the last email) can
control this behavior if it is important.
Possibly it will even get worse;
think of modern approaches like copy-on-write as it is implemented in
Sun's ZFS. If bacula doesn't respect its environment it is bacula's
fault and it is a bacula performance issue. IMO bacula should be
concerned about performance.
I'm not going to repeat what I said before, but I second it again here.
This typical open source "it's not my/our software's fault" is one of
the reason why open source software is mostly hacker's playground stuff.
Perhaps you should think a third time about this.
Annoyed,
/hm
