Date: Mon, 27 Feb 2017 10:08:54 +0100 From: Jan Bramkamp <crest@rlwinm.de> To: Sergey Matveychuk <sem@semmy.ru>, freebsd-fs@freebsd.org Subject: Re: ufs2+su+journal-snapshots Message-ID: <83019546-b7a8-52cf-7fed-768874b50d42@rlwinm.de> In-Reply-To: <ae888c5d-bb2f-b6a4-cfdf-138efc403901@semmy.ru> References: <ae888c5d-bb2f-b6a4-cfdf-138efc403901@semmy.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26/02/2017 19:59, Sergey Matveychuk wrote: > Hi. > > I know, it's an annoying question but is there a plan to fix snapshots > with journaling? May be any project to try and to test? > > Journal enabled in default install now and we lost snapshots (and > backups). It does ufs2 almost useless now. Sure, I can disable > journaling and back to 2000s but it's sadly. > > Many fellows has moved to ZFS and I did the same on a few servers but > often ZFS is overkill (and slow) for me. I'm just reporting hearsay from the last EuroBSDcon, but afaik there is nobody working on UFS with SU+J and Snapshots. The main problem is the interaction of the SU+J code and Snapshots across reboots. Apparently it would be a lot simpler to implement Snapshots that are lost at shutdown. This would be enough for dump -L and other backup tools. Disabling just the journaling part of the soft-updates isn't that bad for small file systems. It should even improve performance in most cases, but it requires a *background* fsck after an unclean shutdown. On small file systems this isn't a huge problem. It becomes a problem if either the ratio of bandwidth to capacity or the ratio of physical RAM to capacity become too large. In either case ZFS and (a bit) more RAM is the best solution available in FreeBSD.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?83019546-b7a8-52cf-7fed-768874b50d42>