player-x schreef op zondag 12 mei 2013 @ 22:57:
Maar zelfs als ik nu zou moeten kiezen, zou ik toch nog voor BTRFS gaan, het is nog steeds zo dat de basis [nog] steeds betrouwbaarder is dan NTFS en ext4, en er komen geregeld nieuwe updates uit die het weer betrouwbaarder maken.
Btrfs is niet volwassen, en zoals Q zegt: als je
nu moet kiezen, dan kijk je naar de status hoe Btrfs er
nu uitziet. En dat is er één in de bèta-fase. Het werkt, meestal, maar soms ook niet. Dat wil zeggen dat mensen er goede ervaringen mee kunnen hebben en niet tegen problemen zijn opgelopen. Andere mensen hebben wel negatieve ervaringen zoals slechte stabiliteit maar ook datacorruptie problemen.
Dat Btrfs nu verkrijgbaar is in Linux en er
geregeld nieuwe updates voor komen, zoals je zelf zegt, is ook juist een slecht teken. Een stabiel filesystem hoort geen updates te krijgen; hooguit nieuwe versies maar updates voor een filesystem zijn normaliter een héél slecht teken.
Om je geheugen te verversen geef ik enkele voorbeelden van hoe het normaliter gaat binnen Linux, dit maal voor Ext4:
EXT4 Data Corruption Bug Hits Stable Linux Kernels
There Might Be Another EXT4 Corruption Bug
Another EXT4 Corruption Bug Gets Fixed
Dit alles terwijl in Ubuntu Ext4 allang het default filesystem was. Ik heb er persoonlijk ook mee te maken gehad. Bedenk hierbij dat Ext4 eigenlijk een héél simpel filesystem is wat afkomstig is van UFS - een filesystem wat afkomstig is van de jaren '80. Dit is elke keer geupdate; Ext2 is vrijwel gelijk aan UFS, Ext3 voegt een journal toe, Ext4 voegt extents toe en grotendeels async I/O. Eigenlijk zijn dit relatief kleine updates voor een vrij oud filesystem. Oud maar eigenlijk supersimpel. NTFS is ook supersimpel.
Hoe simpeler een filesystem, des te lager de potentie voor bugs. Des te complexer een filesystem, des te groter de kans op bugs met name bugs die zich alleen in specifieke situaties voordoen.
Het grootste nadeel van ZFS (en ook Btrfs) is de complexiteit van dit filesystem. Dat bepaalde cruciale code in ZFS slechts enkele kilobytes groot was, werd dan ook als groot voordeel gezien. Compacte, efficiente code die goed getest kan worden. Desondanks was ZFS een vrij zware bevalling; ondanks dat veel operating systems er van wilden kunnen genieten en dus heel veel aandacht besteden aan het stabiel krijgen van ZFS. Toch is dit een proces van meerdere jaren. En pas recentelijk is ZFS echt volwassen; ik zou zeggen sinds versie 15.
Daarnaast geldt dat ZFS niet iets was je zomaar copy-paste binnen een OS kunt integreren. De wijze van integratie is bepalend voor de uiteindelijke stabiliteit. Het is niet moeilijk om dataloss bugs te introduceren bij deze integratie, met name bugs die moeilijk zijn te achterhalen of alleen in zeer specifieke gevallen voordoen.
Bedenk verder ook dat een ervaring heel binair is. Waarmee ik bedoel: of het werkt en je hebt geen problemen ondervonden, dan zeg je gelijk het is stabiel bla bla bla want het werkt bij mij. Totdat je een keer wél een bug tegenkomt en je datacorruptie ondervindt in erge of minder erge mate. Zo zijn er toch wel wat mensen die zich al gebrand hebben aan Btrfs. Het is echt super-beta voorlopig. Dat betekent dat het heel goed kán werken. Maar als het mis gaat, kan het ook goed misgaan.
Ik kan het behalve voor testen of minder belangrijke zaken voorlopig
niet aanraden. Zo was ZFS ook pas na jarenlange bughunting betrouwbaar genoeg om door jan en alleman gebruikt te worden. Zelf heb ik ZFS in gebruik nog voor de tijd dat het voor het eerst geïntroduceerd werd in FreeBSD 7.0. Dan krijg je ook een goed idee wat stabiliteit echt betekent: zo werkt alles prima en denk je dat het goed werkt, volgende boot huppa corrupte pool alles kwijt. Dat bedoel ik met een
binaire ervaring.
Wat snelheid betreft is ZFS met 1GB geheugen nog steeds ruim voldoende om de 1Gbit van je netwerk vol op 100% te laten gaan
Dit is ook niet helemaal juist. Door het transactie-model kun je namelijk hoge timeouts krijgen. Dit kan betekenen dat je tijdelijk wel je netwerk I/O volkrijgt, maar dat een of meerdere seconde de netwerk I/O ook helemaal stopt en je dus een enorm hoge latency krijgt wat zelfs kan zorgen voor stotterende videos die je afspeelt terwijl je bestanden aan het kopiëren bent. Dus dat 1GiB RAM voldoende is voor 1 gigabit netwerk, is een stelling die ik zelf niet zou maken. Het hangt van veel factoren af of weinig geheugen ook goede en vooral stabiele prestaties oplevert. Vaak is tuning nodig om voor jouw specifieke situatie met weinig RAM de beste performance te krijgen. Vaak moet je iets inleveren op absolute prestaties, om meer
consistente prestaties te verkrijgen.
Om heel eerlijk te zijn, player-x, heb ik dat gevoel soms wel bij jou. Je bent echt wel deskundig op bepaalde gebieden. Je hebt de interesse en je weet er genoeg van om mee te kunnen praten. Echter, je bent vaak wel erg stellig in je meningen. Wat jij vindt, is gewoon zo. Je bent te weinig genuanceerd in je meningen. Voorbeeld is je mening over TDP, wat je gewoon onzin vindt dat is alleen voor sukkels - althans dat is mijn korte samenvatting van jouw mening daarover. Zelf zou je het vast anders uitleggen, maar ik wil je wel graag meegeven dat ik je meningen vaak ongenuanceerd vind. Dat wil zeggen, je hebt best goede argumenten, maar de zaken iets minder stellig brengen en wat nuance aanbrengen zou je verhaal veel geloofwaardiger maken en daarmee ook bruikbaarder voor anderen. Dat wilde ik je nog even meegeven. NOFI verder.
de core van BTRFS is zeker veel stabieler dan NTFS en ext4, heb het hier nog onlangs over gehad met mijn vriend een echte Linux guru, en iemand die zich beroepsmatig met Linux bezig houd.
Beroepsmatig met Linux bezighouden betekent nog niet dat iemand de wijsheid in pacht heeft. Er zijn héél veel mensen beroepsmatig met Linux bezig, en daar zitten veel knuppels tussen.
Verder zou ik zeggen dat je vetgedrukte stukje ook een misverstand is. Btrfs heeft meer features en lagen van bescherming. Maar stabiliteit is wat anders dan beveiligingsmechanismen. Zo zijn FAT32 en NTFS en UFS en Ext2 superstabiele filesystemen - stabieler kan bijna niet - maar door hun simpliciteit kunnen ze geen hoge mate van bescherming bieden. De enige bescherming die ze hebben, is tegen een hardeschijf die zijn DRAM-buffer verliest; en daar vallen eigenlijk FAT32 en Ext2 zelfs al niet onder.
Btrfs en ZFS kunnen dus in potentie een véél hoger niveau van bescherming bieden omdat ze meer mechanismen hebben om je data te beschermen, maar stabiliteit kan meer omschreven worden als volwassenheid van de code. Pas als het filesystem geen updates meer krijgt, geen patches, en er geen bugs meer worden ontdekt - pas dan kun je iets stabiel noemen IMO.
Alleen onder andere de de "Online volume growth and shrinking" functie was absoluut nog niet stabiel
Dat zal ook altijd een risico blijven, omdat dat inherent is aan de feature. Wat die feature doet is namelijk bestaande data omspitten en opnieuw indelen. Dat is een risicovolle feature en het gebrek aan ondersteuning hiervoor kan goed te verklaren zijn omdat enterprise-gebruikers dit risico eigenlijk niet willen nemen. De methode van expansion die ZFS kent is inherent veilig omdat bestaande data lekker blijft waar hij is. Ga je rewrite-features toepassen, zoals ook voor ZFS vaak gevraagd, dan ga je bijna automatisch inleveren op stabiliteit gedurende dat de rewrite nog niet voltooid is. Het verhoogt in elk geval in grote mate de complexiteit van de situatie, omdat er allerlei factoren zijn die de veiligiheid van je data bedreigen gedurende dat de rewrite nog niet is voltooid.
[
Voor 5% gewijzigd door
Verwijderd op 13-05-2013 01:09
]
:strip_icc():strip_exif()/u/17654/gertus_icon.jpg?f=community){kind=icon}
:strip_exif()/u/54579/Static.gif?f=community)
/u/1176/crop635f8931b2b68_cropped.png?f=community)
:strip_icc():strip_exif()/u/373647/b1aa8209a437bf987cf066823c044f0a.jpeg?f=community)
