Re: multi volume with tar

On 9 Jun 2006 06:45:27 -0700, heavytull staggered into the Black Sun and
said:
Dances With Crows wrote:
On 8 Jun 2006 05:21:33 -0700, heavytull staggered into the Black Sun
and said:
anyway I've already tried to write directly into the floppy by
doing so: gzip -c my_file.txt>/dev/sdb (sdb is the floppy drive (a
usb one)) it generated plenty of files with some random like names
on the media.
Wait. What? gzipping something and writing the results directly to
a disk definitely won't result in a filesystem-like structure. mount
won't mount that floppy.
yes you're right, there is no known fs for mount when the disk is
directly written with tar or gzip or ... in fact I think the floppy
was already mounted when I did that,

Whoa. You *never* write to the raw device node of a mounted filesystem
unless you know exactly what you're doing. If you did that, yeah, you'd
see completely bogus info when you tried to stat() any files on that
filesystem, because writing directly to the device mangled the
superblock and FAT.

And you can't use compression with multivolume tar, either. If you
want compression, the thing to do is to tar up your stuff with z (or
j) enabled, then pipe it through split -b 1400K, then write each
split file to a floppy that has a filesystem on it.
I attempted to mount a disk written directly with tar and I
couldn't mount it.

Nope.

So I might gain some space when written directly since there is no
filesystem, [right]?

Yes, but the gain's pretty small. FAT was designed for low overhead,
and if you want to compress things, you should create a filesystem
anyway. This is a very good idea because then the filenames let you
tell which part of which archive you've got on a disk.
"archiveNNN.tar.gz.01" through "archiveNNN.tar.gz.05" etcetera, copy
them to a larger disk, cat them all together, untar them. No worries.
No wondering which disk is which. And you can access the files on
non-Linux machines.

This multivolume archive thing is just too much of a PITA in the modern
computing world, though, especially with floppies. CD-R* drives are
cheap, USB keychain drives are cheap, and almost everything has an
Ethernet card. With all that, floppies will soon only be of interest to
computer archaeologists.

--
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin / mail: TRAP + SPAN don't belong
http://www.brainbench.com / "He is a rhythmic movement of the
-----------------------------/ penguins, is Tux." --MegaHAL
.

Relevant Pages

  • Re: USB stick access freezing up system?
    ... would expect the application to fail, but the stick is just a mount in ... How can it corrupt a filesystem on a device that's been removed? ... corruption of its filesystem, ... I have transported an MFM disk that had not been parked with the ...
    (comp.unix.bsd.freebsd.misc)
  • Hints for precision benchmarking...
    ... and run into the usual problem of noisy data preventing any ... * Don't mount filesystems you do not need. ... This removes atime updates to disk from your I/O picture. ... This results in a consistent filesystem layout. ...
    (freebsd-current)
  • Re: having trouble mounting disk image on loopback device
    ... a dd image taken from a physical disk. ... Therefore, to mount each partition, I used these commands: ... mount command will not suffice...For that matter, ... The device must contain a filesystem recognizable ...
    (comp.os.linux.misc)
  • Re: Why are disk writes so slow?
    ... I tried his I/O efficiency program on my IBM ... Can someone explain to me why writing is five times as slow as ... It's probably because of caching on the disk. ... Also, I recommend using a block device, instead of a file on a filesystem, since the filesystem could allocate blocks for the file differently each time, causing varying results. ...
    (freebsd-performance)
  • Re: mount --bind question.
    ... I would *highly* suggest more than two partitions; ... something specific for whatever disk space you have left. ... >back into the right place in the filesystem through symlinks in the root ... but I'm wondering if it would be better to use mount ...
    (comp.os.linux.misc)