Dump time issues

[Kevin Oberman]

On Tue, Oct 28, 2014 at 12:20 PM, Adrian Chadd <adrian at freebsd.org> wrote:

> On 27 October 2014 11:09, Kevin Oberman <rkoberman at gmail.com> wrote:
>
> >> I'm aware of two issues with SU+J, one of which is annoying and the
> other
> > is worse.
> > 1. If the journal is not fully written on power fail or some other
> reason,
> > you may need to do a full fsck of the volume and the behavior of the
> system
> > until this is done can be very unpredictable.
> > 2. You can't safely snapshot the system. This is what 'dump -L' does.
> This
> > means that some files dumped from a live FS may not be consistent (not
> > good!) or, if '-L' is used, the system may well hang.
> >
> > While I love the fast fsck times (2 or 3 seconds) after a crash, I also
> > question the default. Still, it may be a preferred choice be used for
> very
> > large file systems where a full fsck would take a very long time as long
> as
> > the risks are understood. For these systems, ZFS might be a better
> choice.
> > These arguments do NOT favor it being the default, IMHO.
>
> If people can reproduce SU+J problems then please file bugs. There
> have been some fixes with the journal handling over the last year or
> so and I haven't had this problem on -HEAD any longer, but it doesn't
> mean it's there.
>
>
>
>
> -adrian
>

The snapshot issue has been submitted to bugzilla several times. One is
173301. If it has been fixed, great, but the bug has not been touched and I
have not seen any reports of it being fixed. Guess I could try a "dump -L"
on my server and see, but I would hate to see it down for very long if the
problem has not been fixed in 10.1-RC3-p1. Ihave no system running HEAD
ATM, so If any fix has not made it to 10.1, I will not be able to test.

The first issue is probably not a bug, but just very unlucky timing and
does not damage the file system.I have seen many reports with the standard
answer of "run a full fsck" which seems to fix it.