[PATCH] Wipe other file systems when creating new UFS

[Volodymyr Kostyrko]

10.12.2011 18:46, Robert Millan wrote:
> 2011/12/9 Volodymyr Kostyrko<c.kworr at gmail.com>:
>> <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>
>
> This suggests you don't agree with the premise that file systems need
> to be identifiable. We could argue about this, but note that existing
> behaviour is entirely consistent with this premise:
>
> - newfs stores an UFSv2 signature on disk
> - fsck checks for this signature and refuses to operate
> - newfs checks for UFSv1 signature and makes sure it is cleared out
> before creating a new UFSv2
> - the kernel checks for UFS signature before attempting to mount a file system

And how about ZFS?

1. You create zfs pool on the disk.
2. When the pool is created it will be automounted each time. You can't 
format disk with active pool.
3. If you do `export` the pool or move the disk to another computer 
`zpool import` will only report about found pool doing nothing. You need 
explicitly specify pool ident or pool name to import it.
4. If you `destroy` the pool it will not automount in any case.

The most possible way of running into what your patch tries to solve is:
  - create ZFS pool on one machine;
  - don't export it, just move the drive to another machine;
  - on the other machine format the drive as UFS2;
  - accidentally attach the drive to the first machine.

It's not easy to trigger this one as with UFS.

The way I would like this patch would be tasting the drive before 
formatting and refusing to format when any known filesystem is found. I 
know it's very far from the current codebase, but this feels like a 
right way to me.

>> 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.
>
> Ah yes, I probably confused the concepts, I was working from memory
> and it's been a while since I read the spec.
>
>> All vdev labels are _aligned_ to 256k. So technically this is not just last
>> 512k.
>
> I see that you mean.  I guess just aligning down "mediasize" to 256
> kiB before using it would suffice?

Yep I think will do.

-- 
Sphinx of black quartz judge my vow.