label of cache vdev still at /var/zfs/dsk after removal

Moderators: jhartley, MSR734, nola

label of cache vdev still at /var/zfs/dsk after removal

Post by grahamperrin » Sun Mar 24, 2013 3:07 am

First, removing a cache from a pool:

Code: Select all
macbookpro08-centrim:~ gjp22$ zpool offline gjp22 GPTE_64F61AFF-9EBC-4661-9520-7803CD1B8EE4
macbookpro08-centrim:~ gjp22$ zpool remove gjp22 GPTE_64F61AFF-9EBC-4661-9520-7803CD1B8EE4
macbookpro08-centrim:~ gjp22$ sudo zpool status -v gjp22
Password:
  pool: gjp22
 state: ONLINE
 scan: scrub repaired 0 in 28h32m with 0 errors on Tue Mar 19 09:14:12 2013
config:

   NAME                                         STATE     READ WRITE CKSUM
   gjp22                                        ONLINE       0     0     0
     GPTE_71B8BDA2-3EBA-4B91-9E1C-2AE2B1DAAD06  ONLINE       0     0     0  at disk6s2

errors: No known data errors
macbookpro08-centrim:~ gjp22$ ls -l /dev/dsk
lrwxr-xr-x  1 root  wheel  0 23 Mar 20:16 /dev/dsk -> /var/zfs/dsk


Then:

Code: Select all
macbookpro08-centrim:~ gjp22$ ls -l /var/zfs/dsk/GPTE_64F61AFF-9EBC-4661-9520-7803CD1B8EE4
lrwxr-xr-x  1 root  wheel  12 23 Mar 20:16 /var/zfs/dsk/GPTE_64F61AFF-9EBC-4661-9520-7803CD1B8EE4 -> /dev/disk3s2


Is it proper for that symlink to persist?

I guess so. Someone might wish to:

  • reuse that slice of that disk as a cache vdev for a different pool
  • reconfigure the disk so that ashift=13 is used …
grahamperrin Offline

User avatar
 
Posts: 1596
Joined: Fri Sep 14, 2012 10:21 pm
Location: Brighton and Hove, United Kingdom

Re: label of cache vdev still at /var/zfs/dsk after removal

Post by raattgift » Mon Mar 25, 2013 2:14 pm

Yes, it's proper and extremely handy, since cache and log devices are designed to survive (and not interfere with the correctness of the pool) all types of removal and (re-)addition, planned and otherwise. (There is a corner case that requires operator intervention : a known-dirty log file that is unavailable at import time).

Redeploying a device into a different pool changes the device's GPTE identifier; the ZEVO port DTRT when that happens.

(The GPTE doesn't change when you, for instance, remove it as a cache and add it as a log for the same pool. You can do the reverse too, but if the cache is too small (logs tend to be quite small) you may get a crash.)

A bigger practical problem is when a volume manager type of system (CoreStorage, say, or Softraid) generates UUIDs for IOKit on the fly (at boot or attach time), so that the same underlying logical volume's GPTE_ does not persist across reboots. Storage and log vdev code appears to be highly resilient to this, but cache vdev elements often report "UNAVAILABLE" and require a remove-old-GPTE_.../add-cache-new-diskXX

You can't "reconfigure [a] disk so that ashift=X" is used. ashift is a pool property, set at pool creation time, and is unmodifiable after that point. "ashift" is overloaded in the zdb tool, however, since it's also a pun for the native logical block size reported to the system by the storage device. cf. the discussion about ashift for cache vdevs.
raattgift Offline


 
Posts: 98
Joined: Mon Sep 24, 2012 11:18 pm


Return to General Discussion

Who is online

Users browsing this forum: ilovezfs and 0 guests

cron