Re: Can't mount my hammer filesystem
Sorry, I has thought it was not possible to recover data, I've been trying to remake a hammer FS on the disk with the same name and try to recover it. Of course, it didn't work, but I had to try. Finally it was a bad idea... If you really want a disk image, I could try to reproduce this on a smaller disk (actually it was a 500 Gb disk). It'd be great if we could recover a hammer FS which has its volume header corrupted/overwrited. 2011/2/21 Matthew Dillon dil...@apollo.backplane.com: : :Thanks for your reply. : :I don't remember if I installed it on a disklabel or a slice. I will :be able to know what I did once I get the usb flash disk with the :system and look at the fstab. : :Hopefully, I didn't lose data because I did several backups before :-) Ok, if the data is important we *can* recover it, so don't throw it away, but it might require you making the whole image available to me. I would need to add another option to the hammer recover directive to supply the missing info (if the volume header is truly blown away) and experiment a bit 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 non-trivial to 'guess' it. -Matt
Can't mount my hammer filesystem
Hi, I was using dragonfly bsd 2.8 x64 with 2 hard drives. Each hard drives were hammerfs powered and one hdd was a backup of the other with pfs-master / pfs-slave. The system was on a usb flash disk and it was just very slow and too little . 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 my data back ? How ? I tried some commands unsuccessfully : # hammer -f /dev/serno/S1PZJ1DQ508109.s4 recover /media/dd2/ hammer: setup_volume: /dev/serno/S1PZJ1DQ508109.s4: Header does not indicate that this is a hammer volume # hammer -f /dev/da1s4 recover /media/dd2/ hammer: setup_volume: /dev/da1s4: Header does not indicate that this is a hammer volume # mount_hammer /dev/da1s4 /media/dd2/ /dev/da1s4: Not a valid HAMMER filesystem mount_hammer: mount /dev/da1s4 on /media/dd2/: Inappropriate file type or format # mount_hammer /dev/da1 /media/dd2/ /dev/da1: Not a valid HAMMER filesystem mount_hammer: mount /dev/da1 on /media/dd2/: Inappropriate file type or format I have been searching into the mailing list archives or the man and I can't find something related to my problem Thanks you
Re: Can't mount my hammer filesystem
: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 my data back ? How ? : :I tried some commands unsuccessfully : : :# hammer -f /dev/serno/S1PZJ1DQ508109.s4 recover /media/dd2/ :hammer: setup_volume: /dev/serno/S1PZJ1DQ508109.s4: Header does not :indicate that this is a hammer volume s4 ? Not s4d ? Did you accidently install HAMMER directly on a slice and not install it in a disklabeled partition? Installing boot blocks would have wiped the header if you installed HAMMER in a slice instead of a partition. The hammer recover code needs information from the volume header at the moment. That's the only piece of the disk it needs to be able to do a recovery scan. It's a design bug that will require a media format change to fix. -Matt
Re: Can't mount my hammer filesystem
Thanks for your reply. I don't remember if I installed it on a disklabel or a slice. I will be able to know what I did once I get the usb flash disk with the system and look at the fstab. Hopefully, I didn't lose data because I did several backups before :-) 2011/2/20 Matthew Dillon dil...@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 on both disks ? :Can I get my data back ? How ? : :I tried some commands unsuccessfully : : :# hammer -f /dev/serno/S1PZJ1DQ508109.s4 recover /media/dd2/ :hammer: setup_volume: /dev/serno/S1PZJ1DQ508109.s4: Header does not :indicate that this is a hammer volume s4 ? Not s4d ? Did you accidently install HAMMER directly on a slice and not install it in a disklabeled partition? Installing boot blocks would have wiped the header if you installed HAMMER in a slice instead of a partition. The hammer recover code needs information from the volume header at the moment. That's the only piece of the disk it needs to be able to do a recovery scan. It's a design bug that will require a media format change to fix. -Matt
Re: Can't mount my hammer filesystem
: :Thanks for your reply. : :I don't remember if I installed it on a disklabel or a slice. I will :be able to know what I did once I get the usb flash disk with the :system and look at the fstab. : :Hopefully, I didn't lose data because I did several backups before :-) Ok, if the data is important we *can* recover it, so don't throw it away, but it might require you making the whole image available to me. I would need to add another option to the hammer recover directive to supply the missing info (if the volume header is truly blown away) and experiment a bit 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 non-trivial to 'guess' it. -Matt
Re: Hammer filesystem
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 reclaim space by pruning snapshots on less important PFSes, such as /usr. -- vs
Re: Hammer filesystem
: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 mk.conf or something like :that. There's another one to enable the symlink functionality that I can't :remember. : :Petr It's called WRKOBJDIR. I always put this in my /usr/pkg/etc/mk.conf: WRKOBJDIR= /usr/obj/pkgsrc 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. -Matt Matthew Dillon dil...@backplane.com
WRKOBJDIR (was Re: Hammer filesystem)
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 - however: I could see a few reasons for this - 1) pkgsrc 'stuff' stays on the same partition 2) makes it easier to port stuff - as you just cd up or down a few ./..'s - e.g. diff file file ../../patches/patch-q cp hackedonfile ../../ for safe keeping, etc although, a few shell bits in ~/.profile sort that out.. 3) less confusing for new folks definately understand the desire to keep all 'build' stuff in /usr/obj too.. plus it's 'how things have always been done' (TM) right? ok. yeah.
Hammer filesystem
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 == http://sdf.lonestar.org/ ==
Re: Hammer filesystem
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 minimize that effect, check man hammer on viconfig. Jan -- professional: http://www.oscar-consult.de private: http://neslonek.homeunix.org/drupal/
Re: Hammer filesystem
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 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 == http://sdf.lonestar.org/ ==
Re: Hammer filesystem
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 minimize that effect, check man hammer on viconfig. Jan 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 mk.conf or something like that. There's another one to enable the symlink functionality that I can't remember. Petr
New catastrophic HAMMER filesystem recovery tool in HEAD
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 image is only scanned, not modified. The reconstructed filesystem is stored in the target directory. Currently the directive has some limitations. It does require the volume header to be intact, it doesn't deal with hardlinks (only one namespace will be restored), and it does not try to recover the uid, gid, modes, or times. Only files and directories are recovered. Softlinks are ignored at the moment. Data CRCs are not validated at the moment. Most of these limitations can be overcome with more work. -- The actual operation of the recover directive is very cool. Apart from the needing the volume header it just scans the image straight out looking for blocks that contain B-Tree nodes. It then scans those nodes looking for inode, directory-entry, and file-data records and creates them on the fly (piecemeal) in the target_dir. Files and directories are initially named after their object id but as the operation continues and more fragmentory information is recovered the program can reconstruct the actual file and directory names and the actual directory hierarchy, which it does by renaming the temporarily named and placed files and directories as appropriate, on the fly. HAMMER might never have an fsck command but we do now have a 'recover' feature and I expect it will get better and better as time passes. -Matt Matthew Dillon dil...@backplane.com
