Dragonfly BSD

2009.08.07. 21:12

Hunger bíztatására gondoltam nekiállok kipróbálni a Dragonfly BSD-t is, hiszen a legújabb, 2.2-es kiadásban már production ready-nek van jelölve a HAMMER fájlrendszer.

Mivel a rendszer a FreeBSD 4-es forkja, kimaradt a masszív párhuzamosításból (pont ez volt a válás egyik oka), és az ötössel beindult nagy változások, és a kis számú fejlesztő miatt más dolgokból is (amd64 -bár ez lassan készül-, driver frissítések stb).

Emiatt túl sokat nem várok tőle, bár az egy szálú sysbench teszteken valószínűleg még előny is lehet abból, ha a kernelben nincs annyi mutex, mint a solari^Wkutyában a bolha, de ezt majd meglátjuk.

Azért majd, mert a tesztek sokáig futnak, illetve most nem is futnak, mivel pár bájt diszkre írása után a kernel read onlyba kapcsolta a fájlrendszert, és ezt logolta le:

(da1:ciss1:0:1:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0
(da1:ciss1:0:1:0): CAM Status: SCSI Status Error
(da1:ciss1:0:1:0): SCSI Status: Check Condition
(da1:ciss1:0:1:0): ILLEGAL REQUEST asc:20,0
(da1:ciss1:0:1:0): Invalid command operation code
(da1:ciss1:0:1:0): Unretryable error
HAMMER(test): Critical error inode=-1 while flushing meta-data
HAMMER(test): Forcing read-only mode
HAMMER(test): Critical error inode=-1 while flushing meta-data
HAMMER(test): Critical write error during flush, refusing to sync UNDO FIFO

Az UFS egyébként jól működik (nyilvánvalóan nem akar cache-t szinkronizálni), de a ciss driverben azért célszerű lenne ezt az esetet lekezelni...

Megírtam a szitakötős arcoknak, remélem javítják, mert nekem most nincs kedvem Dragonfly BSD-t fordítani...

A bejegyzés trackback címe:

https://suckit.blog.hu/api/trackback/id/tr81295549

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Hunger 2009.08.08. 12:18:40

Hmm, szivacs. Ha Matt igazat mond és FreeBSD-nél is ki van kapcsolva a workaround (nem ellenőríztem), akkor viszont ott vagy a ZFS sem használ cache szinkronizálást vagy másképp oldja meg.

Elküldted neki a dmesg kimenetet? Lehet nem úszod meg a kernel fordítást... :)

blackshepherd · http://suckit.blog.hu 2009.08.08. 18:25:20

@Hunger: ja, ez most engem is elbizonytalanított kissé. Nem tudom mi történik akkor a FreeBSD-ben...
Elküldtem, és inkább fordítottam új kernelt (SMP-set), mintsem Mattől kérjem.
Már fut is a cucc (igaz, ez 2.3.2 lesz, azaz aktuális fejlesztői verzió, mert nem figyeltem a git clone-nál).
Nem tudom UP kernellel érdemes-e megnézni. Érdekesnek érdekes lehet, de ki az az állat, aki HAMMER-t használna, és lemondana a több CPU-ról?

Hunger 2009.08.08. 19:12:38

@blackshepherd: gondolom a többi rendszernél is SMP kernelt használtál és azzal teszteltél, úgyhogy akkor itt is így logikus, nehogy hátrányos megkülönböztetésben részesítsd szegényt! ;P

blackshepherd · http://suckit.blog.hu 2009.08.08. 19:38:22

@Hunger: a FreeBSD-ben elég rég az SMP a default, de hát a dfly kicsit korábbról származik. :)
Rögtön be is szoptam a HAMMER-t, mivel nem töröl, így pikkpakk be is telt a diszk.
Nem olvastam nagyon utána, de azt vártam volna, hogy ilyenkor ne álljon meg az egész, hanem szabadítsa fel a helyen önműködően. Ez most nem így van, a felszabadításra egy éjszakánként futó cronjobot javasolnak.

Nem is tudom... Elég könnyű DoS target...

blackshepherd · http://suckit.blog.hu 2009.08.08. 19:40:22

Egyébként ez a flush (gondolom) eléggé betesz neki. Szekvenciális írás teszt UFS-en, és HAMMER-en 1kiB-os blokkmérettel:
HAMMER:
#bklsize[kB] MBps iops min avg max 95% - idok ms-ban
1 .06 71.57 0.0000 0.0000 0.0004 0.0000
UFS:
1 .44 460.00 0.0000 0.0000 0.0003 0.0000

(71 vs. 460 IOPS...)

Hunger 2009.08.09. 14:51:10

@blackshepherd: hm, mondjuk én azt hittem, hogy mindig a legrégebbi, nem aktuális adatot írja felül, amikor már kevés a hely, amit esetleg meg lehetne még tweakelni azzal, hogy taggelni lehessen bizonyos fileokat/könyvtárakat, amiknek a korábbi változatait akkor se írja felül, ha már nincs hely. Így lenne jó, mert akkor nagyobb diszk/partíció esetén ki lenne használva mindig a hely és lenne valamiféle backup/snapshot a régebbi adatokról is.

Kérdezgesd szerintem nyugodtan Mattet ezzel kapcsolatban, mert gondolom nem az a végső elgondolás, hogy majd a user cronból pucol maga után. Esetleg az is kérdéses lehet, hogy ezt a featuret nem lehet-e kikapcsolni bizonyos esetekben, mert akkor úgy az fsync()-et végrehajtó teszteknél is jobban muzsikálna.
süti beállítások módosítása