gmirror + ZFS issues

[Karl Denninger]

On 5/16/2014 9:18 AM, Nicolas Haller wrote:
> On 16/05/2014 09:36, Karl Denninger wrote:
>>
>> On 5/16/2014 8:23 AM, Nicolas Haller wrote:
>>> Hello,
>>>
>>> I've got a new server and I installed FreeBSD 10 on it. I have a
>>> problem to create a new zfs pool. The command stalls on IO wait (D
>>> state / zio->io_cv).
>>>
>>> The device for the pool is a 1.7T partition (index 4) of a gmirror
>>> device.
>> Why?
>>
>> ZFS provides its own mirroring and it is superior, as it checksums each
>> block and thus does not rely on the drive returning an error to detect
>> problems.  It can also rewrite a bad block (assuming the problem is
>> transient) and scrub also relies on independent components.
>>
>> You're destroying the data integrity advantage that ZFS gives you by
>> using a gmirror under it.  Stop doing that and see if your problem
>> disappears.
>>
>> (In other words it sounds like the problem is real but you shouldn't be
>> doing that anyway, so it also shouldn't bite you.)
>>
>
> Yes you're right but I have two disks on this server which host my 
> non-zfs root fs. The first 98G partition you show on "gpart show" 
> output is my UFS root fs and I want it mirrored.
>
> As I'm not sure it's a good idea to mix gmirror and ZFS mirror on the 
> same drives (What do you think about this?), I let gmirror handle the 
> mirror thing.
There are ways to do that (e.g. gmirror a partition or slice; yes, that 
works) but I wouldn't for several reasons (complexity and the risk of 
making a mistake in the future that winds up screwing you.)
> So, yes, I drop the data integrity advantage, but I keep the 
> flexibility given by pools/datasets, send/receive, compression...
> It's not so bad :-)
>
Ah, ok, I see what you're doing.... I opted to switch my root partition 
to zfs and boot from a mirrored ZFS volume.  If I'm going to run ZFS 
*anyway* then I figure I may as well boot from it.

There is a potential risk in doing that however -- if something goes 
wrong with the zfs code you're in deep kimchee.  This is most-likely if 
your emergency boot media is incompatible with a feature flag in the 
on-disk data set.  You have to be CAREFUL doing this to avoid getting 
nailed; UFS boot is arguably "safer" in that regard, I suppose in that 
if push comes to shove the individual disks in a gmirror can be mounted 
since the metadata is confined to the tail end of the drive.

-- 
-- Karl
karl at denninger.net


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2711 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20140516/5a75df53/attachment.bin>