but that isn't the
real problem. The real problem is that the volume header contains a
single piece of info, the data zone offset relative to the base of the
hammer filesystem, and it's a bit non-trivial to 'guess' it.
-Matt
the system on and
then get back my data from the slave. But, that's not cool, when I try
to mount I get this message Not a valid HAMMER filesystem.
Did I destroyed the filesystem by installing the bootblock on both disks ?
Can I get my data back ? How ?
I tried some commands unsuccessfully
:Hi,
:
:So I deciced to format the master drive to install the system on and
:then get back my data from the slave. But, that's not cool, when I try
:to mount I get this message Not a valid HAMMER filesystem.
:
:Did I destroyed the filesystem by installing the bootblock on both disks ?
:Can I get
...@apollo.backplane.com:
:Hi,
:
:So I deciced to format the master drive to install the system on and
:then get back my data from the slave. But, that's not cool, when I try
:to mount I get this message Not a valid HAMMER filesystem.
:
:Did I destroyed the filesystem by installing the bootblock
to figure out what the offset is in the image.
I've been meaning to add the option for a while now but that isn't the
real problem. The real problem is that the volume header contains a
single piece of info, the data zone offset relative to the base of the
hammer filesystem, and it's a bit
I've regularly run hammer on a 20gb disk and currently on a pair of 40's; my
snapshot retention time is set to 3600 days; no explosions yet.
Just as long as you keep an eye on strikethe rearview mirror/strike df
-h and reblock regularly, you'll be fine. Even if your hammer fills up, you
can
:The biggest consumer of spaces is pkgsrc work directories I find. We
:should provide a better default mk.conf that uses /usr/obj/pkgsrc and
:symlink's the per-package work directory to that instead of unpacking
:directly in the package directory.
:
:I think the variable is called WKROBJ_DIR in
Matthew Dillon wrote:
I agree that it should be setup that way on default installs. I don't
know why NetBSD defaults to wanting to put the work directories
right smack in the middle of a pkgsrc source tree.
personally I'm agnostic here -
I'll have a custom build setup either way -
Hi,
A quick (I hope!) question re: HAMMER.
I've obviously read that it's intended for a minimum filesystem size of
50GB, but if I wanted to try it out on a smaller size what sort of
problems am I likely to see?
Cheers,
Steve
--
SDF Public Access UNIX System - est. 1987
==
Am 03.11.2010 22:11, schrieb Steve:
I've obviously read that it's intended for a minimum filesystem size of
50GB, but if I wanted to try it out on a smaller size what sort of
problems am I likely to see?
Filesystem filling up very quickly. You could try to reduce the amount
of historic data to
Hi,
this thread has some info about this:
http://leaf.dragonflybsd.org/mailarchive/users/2010-04/msg00195.html
Regards,
Jonas
On Wed, Nov 3, 2010 at 10:11 PM, Steve spk+dfus...@sdf.org wrote:
Hi,
A quick (I hope!) question re: HAMMER.
I've obviously read that it's intended for a minimum
Am 03.11.2010 22:11, schrieb Steve:
I've obviously read that it's intended for a minimum filesystem size of
50GB, but if I wanted to try it out on a smaller size what sort of
problems am I likely to see?
Filesystem filling up very quickly. You could try to reduce the amount
of historic data
I've made a good first attempt at writing a HAMMER filesystem
recovery directive to the hammer utility. It is now in HEAD.
It works on the filesystem image (similar to the 'show' directive):
hammer -f device recover empty_target_dir
This is not a fsck. The filesystem
13 matches
Mail list logo
