Date: Sat, 1 Nov 2014 11:52:29 -0700 From: Kevin Oberman <rkoberman@gmail.com> To: Chris H <bsd-lists@bsdforge.com> Cc: Adrian Chadd <adrian@freebsd.org>, freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: Dump time issues Message-ID: <CAN6yY1sy4niL0ohcfYz_vC9uThhfwFd89G0bDYySu_UU1-TsYQ@mail.gmail.com> In-Reply-To: <CAN6yY1utwTwNPFvVKwSYOx=6HMqkZZ1DEFAxUPAgb8v2C_6Z%2Bg@mail.gmail.com> References: <6978A7BF-3CB7-4088-904D-5A60D755A04C@gmail.com> <20141025113846.GY1235@albert.catwhisker.org> <CAN6yY1tp%2Box6jHVnFJ4m3AYf4bBY-OzEfTnwrBHZZ0wwEARAxg@mail.gmail.com> <6bb4cda435fb420fb663fa1d47b85a08@ultimatedns.net> <CAN6yY1sOothUj1i5tTKPHDYNZ%2BCQ3ZKxmYrmq_GE4Ft66LPcBw@mail.gmail.com> <CAJ-Vmo=ahsmVPAmidB33NTtKmxv0QDvp%2BU4Mua3=z1bjQ4dC0w@mail.gmail.com> <9c5f3b0230bf63d32ee8a83e81b1f167@ultimatedns.net> <CAN6yY1utwTwNPFvVKwSYOx=6HMqkZZ1DEFAxUPAgb8v2C_6Z%2Bg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 1, 2014 at 11:47 AM, Kevin Oberman <rkoberman@gmail.com> wrote > On Fri, Oct 31, 2014 at 8:10 AM, Chris H <bsd-lists@bsdforge.com> wrote: > >> On Tue, 28 Oct 2014 12:20:01 -0700 Adrian Chadd <adrian@freebsd.org> >> wrote >> >> > On 27 October 2014 11:09, Kevin Oberman <rkoberman@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. >> Problem existed on RELENG_9 as of 1 mos, and 1 wk. ago. I don't >> have any useful output to provide (I simply blew away the system >> && re-installed w/o SU+J). >> >> --Chris >> > > You should be to deal with that using "tunefs -j disable". Much easier > than re-installing. > > Would disabling soft updates journaling, snapshotting, and re-enabling > would work around the issue? I might play with this when I get a chance. If > it works, perhaps tools (mostly dump -L) could check for SU+J and turn it > off for the time to snapshot the file system. I'm just not sure how well > re-enabling works. Certainly some journal data would be lost, but the > snapshot operation should make that irrelevant. I just don't know that I > understand the details of SU+J well enough to know whether this would make > sense. > Memo to self: Don't type stupid responses while watching football games! Enabling/disabling soft updates journaling requires unmounting the file system, and re-mounting after the change. In the case of root (or a single file system), it would require a reboot. A bit too intrusive for many cases. Why do I realize these things a few seconds AFTER hitting "Send"? -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1sy4niL0ohcfYz_vC9uThhfwFd89G0bDYySu_UU1-TsYQ>