People who use HAMMER also tend to backup their filesystems using
the streaming mirroring feature. You need a backup anyway, regardless.
definitely. Backups are different thing.
But i do not consider online mirroring from hammer as backup feature, but
something like more sophisticated
I am NOT talking about background fsck which is implemented in FreeBSD and
i turn this off.
I am talking about just not doing fsck of every filesystem after crash.
And doing it within same day but when pause is not a problem.
This is legitimate method with UFS+softupdates.
Then explain
HAMMER(ROOT) recovery check seqno=8ca97e62
HAMMER(ROOT) recovery range 36877528-36892fa0
HAMMER(ROOT) recovery nexto 36892fa0 endseqno=8ca98015
HAMMER(ROOT) recovery undo 36877528-36892fa0 (113272 bytes)(RW)
ad4: FAILURE - READ_DMA48
On 19/07/12 09:25, Wojciech Puchar wrote:
this is example of what i fear about hammer. One error results in
unability to mount.
If it is just software error in hammer that's great. If it is design...
not great.
This is not a hammer problem but a problem with the underlying disk. It
couldn't
On Thu, Jul 19, 2012 at 1:59 PM, Alex Hornung ahorn...@gmail.com wrote:
This is not a hammer problem but a problem with the underlying disk. It
couldn't read from the disk - that is pretty much a file-system
independent problem; UFS would fail equally miserably.
I have PFS slaves on a second
not great.
This is not a hammer problem but a problem with the underlying disk. It
couldn't read from the disk - that is pretty much a file-system
independent problem; UFS would fail equally miserably.
not true.
it is very unlinkey case you will not be able to mount. you will not be
able to
Wojciech Puchar writes:
not great.
This is not a hammer problem but a problem with the underlying disk. It
couldn't read from the disk - that is pretty much a file-system
independent problem; UFS would fail equally miserably.
not true.
it is very unlinkey case you will not be able to mount.
UFS use flat on disk structure. inodes are at known places.
I don't know how HAMMER data is placed, but seems everything is dynamic.
any link to description of HAMMER on disk layout?
Please, read hammer(8) (at the subcommand recover).
thank you very much.
While such recovery is painfully
On Thu, Jul 19, 2012 at 12:42:02PM +0200, Wojciech Puchar wrote:
UFS use flat on disk structure. inodes are at known places.
I don't know how HAMMER data is placed, but seems everything is dynamic.
any link to description of HAMMER on disk layout?
Please, read hammer(8) (at the
which i don't have at the moment.
just dd /dev/random and overwrite a few sectors?
good but... real failures are always worse than that.
In my tests ZFS for example (which for me is plain example of bad design
and bad implementation) failed within less than hour to the point it was
This was under FreeBSD but DragonFly UFS is no different.
My main problem had been with ffs_fsck. At one point my machine was
randomly crashing due to a bad power supply. Everytime I started up, did
an hour of work, then crash, then 30-40 minutes for fsck to run, and an
hour later do it all
My main problem had been with ffs_fsck. At one point my machine was
randomly crashing due to a bad power supply. Everytime I started up, did
an hour of work, then crash, then 30-40 minutes for fsck to run, and an
you may postpone fsck when using softupdates. It is clearly stated in
Wojciech Puchar writes:
My main problem had been with ffs_fsck. At one point my machine was
randomly crashing due to a bad power supply. Everytime I started up, did
an hour of work, then crash, then 30-40 minutes for fsck to run, and an
you may postpone fsck when using softupdates. It is
you may postpone fsck when using softupdates. It is clearly stated in
softupdate documents you may find (McKusick was one of the authors).
that's what i do.
Then, you suffer a performance hit when fsck'ing in bg.
once again - read more carefully :)
I am NOT talking about background fsck
Wojciech Puchar writes:
you may postpone fsck when using softupdates. It is clearly stated in
softupdate documents you may find (McKusick was one of the authors).
that's what i do.
Then, you suffer a performance hit when fsck'ing in bg.
once again - read more carefully :)
I am NOT
OK, understood now, i think: you agree with temporarily loosing a bit of
unreclaimed free-space on disk until time permits cleaning things up
properly, afaiu softupdates (+journalling ? not really clear).
That it. And that's how original softupdates document describe it.
You may run quite
Wojciech Puchar writes:
What i point out that flat data layout makes chance of recovery far higher
and chance of bad destruction far lower.
Any Tree-like structure produces a huge risk of losing much more data that
was corrupted at first place.
Not so sure about that statement, but well,
Any Tree-like structure produces a huge risk of losing much more data that
was corrupted at first place.
Not so sure about that statement, but well, let's agree we might disagree :)
disagreement is a source of all good ideas. but you should explain why.
my explanation below.
You asked
Wojciech Puchar writes:
Any Tree-like structure produces a huge risk of losing much more data that
was corrupted at first place.
Not so sure about that statement, but well, let's agree we might disagree :)
disagreement is a source of all good ideas. but you should explain why.
Well,
Sorry, i also just love ZFS for the business case i rely on it for. It has
some
clearly nice features.
sorry if your resoning for software is based on love, not logic then it's
good idea to end topic.
Probably your business is more about deploying as much as possible and
that's all.
People who use HAMMER also tend to backup their filesystems using
the streaming mirroring feature. You need a backup anyway, regardless.
HAMMER makes it easy, and this is the recommended method for dealing
with media faults on HDDs not backed by hardware RAID (and even if
they
:I have PFS slaves on a second disk.
:I have already fitted a new disk and the OS installation is complete.
: I will upgrade the Slaves to Master and then configure slaves for
:them so there is no problem.
:
:But I have lost the snapshot symlinks :-(
:In the PFSes I snapshotted every 5 minutes I
On Fri, Jul 20, 2012 at 9:35 AM, Matthew Dillon
dil...@apollo.backplane.com wrote:
Try 'hammer snapls mountpt'. The snapshots are recorded in meta-data
so if they're still there you can get them back. You may have to
write a script to recreate the softlinks from the output.
Yes
23 matches
Mail list logo
