lastlog devours universe

[Andy Ross]

Jesse Keating wrote:
> Michael Wiktowy wrote:
> > In your experience, is there a reason not to use --sparse in most
> > occasions?  Usually sensible defaults are the best way to go and if
> > 99% of the time, you want your tar to "condense" sparse files, then
> > it is likely best to make it do that by default.
>
> And then we have an even longer thread about tar changing it's default
> behavior and pissing off even MORE admins who have been using tar for
> decades on not just Linux.  That is a VERY silly suggestion.

In a final attempt to inject some facts to this conversation, I
actually tried the --sparse option.  Indeed, it produces a very small
file.  It also takes forever to do it.  Apparently tar implements
sparse files by simply detecting and condensing large blocks of zeros
in the input file, which means that it has to actually read all 1.2TB
of nothingness to do its job.

It's been working for 52 minutes now on my 1.8GHz Athlon64 laptop.  I
have no idea how much longer I will be waiting.

Noting that the same behavior was reported with rsync in bug 156809, I
submit that the --sparse option is actually a very poor workaround for
this issue, even if it avoids the disk explotion issue when tar is used
with more conventional* options.

* Using the words "standard" or "default" in this context got slammed.  Is
  this synonym OK with you?

The bottom line, to my mind, is that the /var/log directory on (64
bit) FC4 systmes has extraordinarily strange characteristics that will
(at best) cause serious performance problems and (at worst) fill up
the output media when the user tries to back it up.  Since this is a
logging directory, and therefore a natural target for user backups, I
think this is a problem that needs to be addressed and not ignored.

Andy