ZFS az opensolaris.org-on

Sun Microsystems

A ZFS hosszas várakozás után megjelent az opensolaris.org-on és debütált a Solaris Nevada build 27-ben.

En arra lennek kivancsi, hogy egy ilyen ujonnan megjeleno filerendszer mennyire stabil. En elhiszem, hogy zsir a sok uj feature, de azert ne felejtsuk el, hogy a sok-sok eves (vagy tizeves) FS-ekben is javitanak sokszor durva hibakat annak ellenre, hogy azok mar erett stuffok.

Plane arra lennek kivancsi, hogy az ilyen uj operacios rendszer funkciokat kik es hanyan tesztelik, mielott elesben belepattintjak mondjuk egy "dobozos" Solarisba, es mondjuk Gipsz Jakab IT specialista rabizza a vallalat ertekes adatait.

( dragi v | 2005. 11. 17., cs – 15:33 )

A demo nagyon impressziv. Jo kis dolgok vannak ebben a zfsben.

( frank | 2005. 11. 17., cs – 16:15 )

Amint a flash demot neztem, kicsit lvm2 filingem volt. Tudom hogy az egyik volume menedzsment alrendszer, a masik meg filerendszer, de akkor is. Lattam az elkepzelesekben valami kozoset.

egyebkent:

Nightly “ztest” program does all of the following in parallel:

● Read, write, create, and delete files and directories

● Create and destroy entire filesystems and storage pools

● Turn compression on and off (while filesystem is active)

● Change checksum algorithm (while filesystem is active)

● Add and remove devices (while pool is active)

● Change I/O caching and scheduling policies (while pool is active)

● Scribble random garbage on one side of live mirror to test self-healing data

● Force violent crashes to simulate power loss, then verify pool integrity

● Probably more abuse in 20 seconds than you'd see in a lifetime

● ZFS has been subjected to over a million forced, violent crashes without losing

data integrity or leaking a single block

innen: http://www.opensolaris.org/os/community/zfs/docs/zfs_last.pdf

( _Joel | 2005. 11. 18., p – 08:06 )

trey.

ZFS tesztelesrol:

http://blogs.sun.com/roller/page/jwalker#zfs_testing

"Testing ZFS reminds me of when I was working for IBM at NASA on the Space Shuttle Flight Software Project..."

http://blogs.sun.com/roller/page/bill#zfs_and_the_all_singing

"So what do you do in order to drive the the number of bugs in a given piece of software towards zero? You write tests. And the end quality of your product depends very directly on how good these tests are at exploring the boundary conditions of your code. If you only test the simple cases, only the simple things will actually work."

:)

Nem problemam annyira. Egyszeruen kivancsi vagyok, hogy egy olyan cegnel, mint a Sun, hogyan folyik a szoftver engineering. Ezert tettem fel a kerdest. Igazabol a tobb erdektelen hozzaszolas mellett (helyett) azt vartam, hogy valami belso ember szepen leirja (tudom, hogy tobben is olvassak a Sun-tol az oldalt (legalabb 3 emberrol tudok :-)), hogy hogyan megy az ilyesmi.

Fogalmam nincs rola. Vannak magyarok kulfoldon engineering poziciokban (Bertold pl, vagy Laca a gnome fejlesztok kozott), de nem tudom ok olvassak-e a hup-ot. Kozep-Europaban pedig Praga beelozott minket: oda es Szentpetervarra veszik fel a fejlesztoket tucatjaval, Budapest egyelore marad sales office.

ugyan nem Solaris (az nem az én asztalom), de
a glassfish (opensource Sun alkalmazásszerver) esetében nemcsak az alkalmazásszerver forráskódja, hanem a QA tesztek jórésze is hozzáférhető:

http://fisheye.cenqua.com/java.net/viewrep/glassfish/appserv-tests [fisheye.cenqua.com]



A fejlesztőcsapat mellet van egy QA csapat, akinek feladata a teszt esetek megtervezése a terméktervezés után, megírása és futtatása, részben manuálisan, jórészt automatizálva.
Ezeken kívül vannak dobozos, nagy alkalmazásokkal végzett longevity (élettartam) tesztek, ahol több hétig pörög az adott alkalmazás miközben monitorozzák az alkalmazásszervert.
Ezenkívül egy performance team különböző teljesítményméréseket végez a build-eken és performanciával kapcsolatos hibákat keres.

A JDK 6 (Mustang)teszteléséről olvashatsz itt [forums.java.net]