> 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 exp
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 m
On Fri, Jul 20, 2012 at 9:35 AM, Matthew Dillon
wrote:
>
> Try 'hammer snapls '. 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 the snapshots are all there.
: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 h
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
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.
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, argui
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 for
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, le
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 saf
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 talking
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 whi
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 clear
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
softupdat
> 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 ov
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
mounta
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 ham
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 s
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. y
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 re
On Thu, Jul 19, 2012 at 1:59 PM, Alex Hornung 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 disk.
I have
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
coul
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 status=51
error=40 LBA=
23 matches
Mail list logo