Zpool'u Ubuntu Xenial'da / dev / disk / by-id kullanmaya zorlamak


16

Ubuntu 16.04 Xenial üzerinde paketlenmiş OpenZFS'yi deniyorum.

Havuzlar oluştururken, her zaman esneklik için /dev/disk/by-id/(veya /dev/disk/gptFreeBSD'de) sürücülerine seri olarak başvuruyorum . /devBir makine yeniden başlatıldığında sürücüler her zaman aynı sırada değildir ve makinede başka sürücüler varsa havuz doğru şekilde takılmayabilir.

Örneğin, zpool status14.04 bir kutu üzerinde çalışan bu olsun:

NAME                                  STATE     READ WRITE CKSUM
tank                                  ONLINE       0     0     0
  raidz1-0                            ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HUA722020ALA330_[..]  ONLINE       0     0     0

Ama bu (kısaltılmış) ile 16.04 yeni bir havuz oluşturduğunuzda:

zpool create pool raidz \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..] \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..] \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..] \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..]

Bunu şu şekilde alıyorum zpool status:

NAME        STATE     READ WRITE CKSUM
tank        ONLINE       0     0     0
  raidz1-0  ONLINE       0     0     0
    sdf     ONLINE       0     0     0
    sde     ONLINE       0     0     0
    sdd     ONLINE       0     0     0
    sda     ONLINE       0     0     0

Görünüşe bakılırsa zpool referans vermek yerine sembolik bağlantıları takip etti.

Havuz oluştururken 16.04'te zpool'u sürücü referanslarıma uymaya zorlamanın bir yolu var mı? Ya da alternatif olarak, burada yaptığı şeyle ilgili yanlış düşüncelerim yanlış mı yerleştirildi?

Güncelleme: Geçici çözüm

Ben bir iş parçacığı bulundu geçici bir çözüm önerdi Github zfsonlinux için. Zpool'unuzu önce /dev/sdXcihazlarla oluşturun , ardından bunu yapın:

$ sudo zpool export tank
$ sudo zpool import -d /dev/disk/by-id -aN

zpool createYine de mümkünse ilk ile bunu yapmayı tercih ederim .


Onları nasıl yarattığınız önemli değil. / Dev / sd'ye dönerse? cihaz adları, zfs exportve zfs import -dyine de çalışır. BTW, gerçekten her alan baytına ihtiyacınız yoksa , raidz yerine iki aynalı çift kullanın. raidz'in performansı raid-5'ten daha iyidir, ancak raid-10 veya zfs aynalı çiftlerden çok daha kötüdür. aynalı çiftlerden oluşan bir havuzu genişletmek daha kolaydır, bir seferde iki disk ekleyin ... raidz ile, her sürücüyü daha büyük sürücülerle değiştirmeniz gerekir ve yalnızca hepsini değiştirdiğinizde havuz daha fazla yer var.
cas

Hala raid-z havuzlarım var ve onları yarattığım için pişmanım. Yedek diskler satın alabileceğimde, aynalı çiftlerle yeni havuzlar oluşturacağım ve zfs sendverilerimi yeni havuzlara kopyalamak için kullanacağım . Aslında, raid-z, aynı anda 6 veya 8 kod dönüştürme işi çalıştırmadığım sürece performansın kritik olmadığı mythtv kutusu için sorun yok. Yansıtılmış çiftlere geçmek, /home dizinimin yaşadığı havuzda çok dikkat çekici olacaktır .
cas

2
ZIL'in aynalanması, güç kaybına karşı korumak için büyük kapasitörlere sahip pahalı olanlardan ziyade sıradan ucuz SSD'leri kullanmaktan kurtulabilirsiniz. IMO, ZIL'in yansıması isteğe bağlı değildir , ne tür SSD'leriniz olursa olsun - ZIL'iniz ölürse, henüz yazılmamış tüm verileri kaybedersiniz ve havuzunuzu potansiyel olarak bozarsınız. L2ARC'ye gelince, özellikle onları yansıtmak için DEĞİL dedim ... L2ARC önbelleğini yansıtmak zaman, para ve iyi SSD alanı kaybıdır (ve önbelleği kaybetmeyi önlemek için hiçbir şey yapmaz - bu fikri nereden aldınız?)
cas

1
:) BTW, ZIL'i yansıtma nedenini açıkladığımda beynim düzgün çalışmıyor. Güç kaybına karşı korumak değil, bu tam bir saçmalık ve bunu asla söylememeliydim. ZIL sürücüsünün arızalanmasına karşı koruma sağlamaktır. yani ZIL için raid-1 aynası. Makul fiyatlı iki SSD genel olarak son derece pahalı olandan daha iyidir (daha pahalı SSD'nin PCI-e ve SATA gibi çok daha hızlı bir arayüzü yoksa). ve bir UPS çok önemlidir ... güç kaybına karşı ucuz koruma.
cas

1
@cas Yansıtılmış ZIL , beklenmedik bir kapanma ile aynı zamanda SLOG cihaz hatasına karşı koruma sağlar . Normal işlemler altında, ZIL salt yazılır ve kalıcı depolamaya RAM'den (ARC) yazılır. Sistem beklenmedik bir şekilde kapanırsa, kesilen yazma işlemlerini tamamlamak için niyet günlüğü (ZIL, SLOG) kullanılır. Yalnızca beklenmedik kapanma bir SLOG aygıtının arızasıyla çakışırsa, kesintiye uğramış yazma işlemlerini kurtarmak için redüktif SLOG gerekir. Çoğu sunucu olmayan (ve birçok sunucu) iş yükü için, ZIL gerçekten sadece senkronize yazmalarla devreye girdiğinden, bir SLOG aşırıya kaçar.
CVn

Yanıtlar:


1

Arada bir, zpool import -d /dev/disk/by-idçalışmıyor.

Bunu birden fazla ortamda fark ettim. Ben de bazı sihirli mantık yapmanın ve fiziksel olarak bağlı ZFS cihazları gösteren, ayrıca temelde bunu yapar bir ithalat komut dosyası var:

zpool import -d /dev/disk/by-id POOL
zpool export POOL
zpool import POOL

-dAnahtar olmadan bile ikinci kez , açık komutla ilk kez olmasa bile cihaz kimliğine göre içe aktarılır.

Bunun sadece birkaç hafta veya bir ay boyunca (bir veya iki yıl önce) bir ZFS hatasından kaynaklanması olasıdır ve bu artık gerekli değildir. Sanırım bir hata raporu hazırlamalıydım, ama etrafta çalışmak önemsizdi.


1

Bu konu bayat bir tür biliyorum, ama bir cevap var. İçe aktardıktan sonra önbellek dosyanızı güncellemeniz gerekir. Bu örnek, önbellek dosyası için varsayılan konumu gösterir.

$> sudo zpool export POOL
$> sudo zpool import -d /dev/disk/by-id POOL
$> sudo zpool import -c /etc/zfs/zpool.cache
$> sudo zpool status POOL
NAME                                  STATE     READ WRITE CKSUM
POOL                                  ONLINE       0     0     0
  raidz1-0                            ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HUA722020ALA330_[..]  ONLINE       0     0     0
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.