Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 25 Feb 2012 14:30:55 +0100
From:      Peter Maloney <peter.maloney@brockmann-consult.de>
To:        freebsd-fs@freebsd.org
Subject:   Re: glabel, gpart and zfs confusion.
Message-ID:  <4F48E28F.9090600@brockmann-consult.de>
In-Reply-To: <4F48A402.70009@brockmann-consult.de>
References:  <3E3E4094-77E2-490B-9574-5B95ECDED447@pean.org> <4F48A402.70009@brockmann-consult.de>

next in thread | previous in thread | raw e-mail | index | archive | help
And btw. related but not an answer to your question...

>From the thread you mentioned:/

/>/ # zpool attach tank label/m00-d00 label/m00-d01
/>/ cannot use '/dev/label/m00-d01': must be a GEOM provider or regular file
/>/ 
/>/ # glabel label m00-d01 /dev/da2s3
/>/ glabel: Can't store metadata on /dev/da2s3: Invalid argument.
/>/ 
/>/ # sysctl kern.geom.debugflags=17
/>/ kern.geom.debugflags: 0 -> 17
/>/ 
/>/ # dd if=/dev/zero of=/dev/da2s3
/>/ dd: /dev/da2s3: Invalid argument
/
My guess is that if you exported the pool, the "Invalid argument" errors would go away.
/
/



Am 25.02.2012 10:04, schrieb Peter Maloney:
> In Solaris, I've read that the IO system is designed such that a some
> commands (eg. flush of a partition) does not necessarily flush the
> disk's write cache... like the command can't move up the chain. So if
> you put zfs on a partition, you can get data loss (eg. transaction
> rollback required and probably no corruption).
>
> In FreeBSD, things are different I am told, without the above
> limitation. So you can happily put zfs on partitions, and the zfs code
> can keep your data safe. I haven't had data loss with system panics
> during sync writes with my ZIL on a partition, so I guess this must be true.
>
> People say that glabel is buggy/a hack. But I haven't had any problems
> myself. So they suggest using gpt to label your disks. I find that
> sometimes your gpt labels get eaten though, and you end up with gptid in
> your zpool status output. For labels to get eaten, you need to import
> the pool elsewhere with -f usually. And maybe this only applies to the
> root pool in most cases (but I definitely had one other case when it
> happened to a different pool). There is something you can add to
> /boot/loader.conf to get rid of the gptids... but I am hesitant to use
> it... because what happens when you have 2 identical labels and gptid is
> gone?
>
> eg.
>
>         NAME                                            STATE     READ
> WRITE CKSUM
>         zroot                                           DEGRADED    
> 0     0     0
>           mirror-0                                      DEGRADED    
> 0     0     0
>             gptid/bcc6c93a-f332-11e0-a5b6-0025900edbca  OFFLINE     
> 0     0     0
>             gptid/4629fb4b-f596-11e0-a5b6-0025900edbca  OFFLINE     
> 0     0     0
>             gpt/root2                                   ONLINE      
> 0     0     0
>             gpt/root3                                   ONLINE      
> 0     0     0
>
> And also if a whole disk goes bad, and you try to replace it with
> another whole disk that is 1 byte smaller, it won't allow you to do
> that. So if you use gpart and create a slightly smaller partition, you
> get the advantage of being able to replace disks with smaller ones later.
>
> For new systems, I am using gpt labels. And if the gptid thing appears,
> I just ignore it.
>
>
> Am 25.02.2012 09:42, schrieb Peter Ankerstål:
>> Hi,
>>
>> Now Im really confused. 
>>
>> I want in some way label my drives so the setup is independent of physical setup. But Jason doesn't
>> seem to like glabel at all. :D
>> http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013574.html
>>
>> And then he says that you should use gpart instead
>> http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013578.html
>>
>> But this seems to be in conflict with the common knowledge that zfs should
>> be used on whole disks, not partitions!
>>
>> Any pointers? 
>> _______________________________________________
>> freebsd-fs@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
> _______________________________________________
> freebsd-fs@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F48E28F.9090600>