Date: Fri, 09 Dec 2011 16:58:01 +0200 From: Volodymyr Kostyrko <c.kworr@gmail.com> To: Robert Millan <rmh@freebsd.org> Cc: freebsd-fs@freebsd.org, Adrian Chadd <adrian@freebsd.org> Subject: Re: [PATCH] Wipe other file systems when creating new UFS Message-ID: <4EE221F9.9010505@gmail.com> In-Reply-To: <20111208134307.GA5266@thorin> References: <20111208134307.GA5266@thorin>
next in thread | previous in thread | raw e-mail | index | archive | help
08.12.2011 15:43, Robert Millan wrote: > This patch resolves a problem reported to Debian BTS [1] which also affects > FreeBSD. The problem is that if you create a ZFS file system in a partition > and later decide you'd rather use UFS and overwrite it, remnants of ZFS > uberblocks are left at the beginning and end of the partition. This can > lead to disaster (data loss) if "zpool import" is attempted, as it would > destroy UFS data structures. > > newfs(8) currently erases remnants of UFS if they exist. I think it should > go further and erase first and last 512 kiB of the partition. > > [1] http://bugs.debian.org/635272 <flame> Shouldn't it make us a coffee then? Making precautions against shooting-the-foot is a wrong choice for me. This way we need to extend it to support any other file system that can repair thyself upon mount in case user mistakenly mounted the wrong one. </flame> What about drives that support SSD? Isn't it convenient to use TRIM in such cases? You messing up ZFS terminology a bit. Uberblock size is 1k and what you refer is ZFS vdev label. Size of vdev label is 256k. There are four vdev labels for each vdev - two at the beginning of the vdev and two at the end. All vdev labels are _aligned_ to 256k. So technically this is not just last 512k. -- Sphinx of black quartz judge my vow.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EE221F9.9010505>