lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <200704091549.51805.gene.heskett@gmail.com>
Date:	Mon, 09 Apr 2007 15:49:51 -0400
From:	Gene Heskett <gene.heskett@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	"John Stoffel" <john@...ffel.org>, Jeff Garzik <jeff@...zik.org>
Subject: Re: I give up

On Monday 09 April 2007, John Stoffel wrote:
>>>>>> "Gene" == Gene Heskett <gene.heskett@...il.com> writes:
>
>Gene> On Monday 09 April 2007, Jeff Garzik wrote:
>>> Gene Heskett wrote:
>>>> Now the 64k$ question: While running with LVM2 managed disks, is it
>>>> possible to run without dm_mod, the device-mapper?  If so, please
>>>> tell me how to achieve this.
>>>
>>> No; device mapper is the kernel portion of LVM2.
>>>
>>> Jeff, who actively avoids LVM on home computers
>
>Gene> Ya shoulda warned me.  :-)
>
>Gene> It should have lots bigger warning labels, in bright red
>Gene> self-illuminating signs, than it does.  It in fact seems to work
>Gene> well, but it is a major breakage for some common apps, like
>Gene> doing backups...
>
>>>From the GNU info doc on the tar program:
>
>    Metadata stored in snapshot files include device numbers, which,
>    obviously is supposed to be a non-volatile value. However, it turns
>    out that NFS devices have undependable values when an automounter
> gets in the picture. This can lead to a great deal of spurious
> redumping in incremental dumps, so it is somewhat useless to compare
> two NFS devices numbers over time. The solution implemented currently
> is to considers all NFS devices as being equal when it comes to
> comparing directories; this is fairly gross, but there does not seem to
> be a better way to go.
>
>This to me, seems to be another borkage of the tar program.  Can you
>tell Amanda to use 'dump/restore' instead of tar instead?  Or heck,
>just move to Bacula, it's smarter than amanda/tar and it supports
>writing to DVDs, etc.  http://www.bacula.org
>
I wouldn't touch dump/restore with a 50 foot pole, particularly since I 
have serious doubts about it viability in the LVM environment.

For those of you with big tapes that can hold a complete dump of every 
partition (and partitions is the only way dump works in case some have 
forgotten), go ahead and use dump/restore.  Tar quite simply, allows one 
to break his backup files down into small enough pieces that a tape drive 
that's only 20% of the system drives size is totally usable.  I ran dds2 
tapes for a long time, and it wasn't at all unusual to have amanda fill 
those to the 95% or better mark every night for a week running, without 
ever hitting EOT.

>This tar borkness is pretty annoying, since Amanda (from the docs
>page) only keeps indexes in terms of host/filesystem/path/date,
>nothing about the major/minor (device) numbers.
>
>It just re-inforces my desire to never use Amanda again.

Your call, that's what this linux thing is all about.  But do I not recall 
your name from the amanda lists at some point in the last 8+ years?
>
>John
>john@...ffel.org

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
<Culus> OH MY GOD NOT A RANDOM QUOTE GENERATOR
<netgod> surely you didnt think that was static? how lame would that 
be? :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ