Mailinglist Archive: opensuse (1606 mails)

< Previous Next >
Re: [opensuse] Re: Transparent content compression for space savings on linux like on NTFS?
  • From: Randall R Schulz <rschulz@xxxxxxxxx>
  • Date: Sun, 31 Aug 2008 19:23:20 -0700
  • Message-id: <200808311923.20632.rschulz@xxxxxxxxx>
On Sunday 31 August 2008 18:22, Brian K. White wrote:

I think the OP already knew about compressed filesystems.
The question was not about compressed filesystems.
It was about treating a zip file as a directory.


Although I don't think I have much use for mounting an archive as a
filesystem, it's interesting to know about none the less. Maybe it's
slightly fewer keystrokes for working on initrd's which are now cpio
files instead of ext2 filesystems.

In my case, the need arose when I devised a set of scripts (additions to
existing ones, actually) to facilitate large-scale experimentation
within a very large space of options and search heuristics for a
theorem-proving system. Prior to this, we'd alter the options or the
search heuristic and run test after test. Sometimes we'd hit on a
propitious combination and later not be able to recreate it.

So I augmented the invocation scripts to maintain a log of compressed
test results. Each run of the prover generally produces many files,
including HTML renderings of the proofs discovered or, failing a
successful attempt, the statistics describing the unsuccessful effort.

With that scheme in place, I wanted a convenient way to access this
history of our experiments. I started by trying to create some scripts
that would help, but they proved cumbersome, so I asked about
better-integrated, more transparent solutions, with reference to my
recollection about a similar capability integrated via Windows

The "archivemount" command (relying as it does on the libarchive library
and on FUSE) was nearly ideal. The only thing I could possibly wish for
beyond what it provides is some kind of automatically triggered
invocation (akin to NFS auto-mounting), but given the huge number of
archives I have to deal with, that probably would entail its own set of
complications and down-sides. E.g., knowing when to unmount an archive
that is no longer in use.

I have one experimental log which currently has 122 gzip-compressed TAR
archives, and archivemount can simultaneously provide them all (not that
I'd typically do that, but it was easy enough to try with a wild-card
invocation). Each one requires a running instance of the archivemount

One final gap is the following. Compare the (elided) output of "mount"
with that of "df." ("am" is my cover script for invoking archivemount):

% am log/latest.tar.gz
% mount
LABEL=Root10 on / type xfs (rw)
/dev/sda1 on /repo type reiserfs (rw)
/dev/sdb1 on /root93 type xfs (rw)
/dev/sdd1 on /root91 type xfs (rw)
/dev/sdd2 on /home type xfs (rw)
/dev/sdd3 on /dar type xfs (rw)
archivemount on /dar/tau/tst/New/log/latest type fuse

% df
Filesystem 1K-blocks Used Available Use% Mounted on
LABEL=Root10 35895684 17805508 18090176 50% /
/dev/sda1 293008588 106776492 186232096 37% /repo
/dev/sdb1 20962560 11336984 9625576 55% /root93
/dev/sdd1 11962304 6421104 5541200 54% /root91
/dev/sdd2 11961344 8485132 3476212 71% /home
/dev/sdd3 11961344 4456652 7504692 38% /dar
df: `/dar/tau/tst/New/log/latest': Function not implemented

I gather from this that archivemount does not implement a file-system
switch function used by the "df" command.

Brian K. White

Randall Schulz
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >
List Navigation
Follow Ups