LVM standardowo dostępne w NetBSD
5 grudnia 2009, blinkkin
Implementacja tego systemu składa się z dwóch części składowych: samego LVM działającego w przestrzeni użytkownika i sterownika Device Mapper w jądrze systemu.
Z powodów licencyjnych zespół NetBSD napisał własny sterownik na licencji BSD, który współpracuje z LVM na licencji GPL. Oznacza to, że doświadczenie wyniesione z użytkowania Linuksa z pewnością się przyda.
Wsparcie dla LVM jest dostępne już dosyć długo. Jednak dopiero po wnikliwych testach i aktualizacji narzędzi tego menedżera do najnowszej wersji 2.02.56 zdecydowano się go udostępnić jako standardową opcję w drzewie –current systemu.
Obecnie dostępne są tylko dwa rodzaje mapowania: liniowe i przeplatane. Trwają prace nad udostępnieniem migawek, kopii lustrzanych, rozwiązań klastrowych i wsparcia dla urządzeń DRB (Distributed Raid Block Device).
Proces tworzenia pozostałych rodzajów mapowań może zostań przyspieszony po przepisaniu sterownika Device Mappera pod RUMPa. RUMP to mechanizm w NetBSD (został przeniesiony także na inne systemy) pozwalający na działanie kodu jądra w przestrzeni użytkownika.
Co ciekawe jest to kolejne narzędzie związane z systemem plików, które w NetBSD znalazło się dzięki pracy Adama Hamsika. Niedawna na EuroBSDCon można było wysłuchać jego prezentacji dotyczącej LVM.
W sumie to RedHat nie stworzył LVM jako takiego, tylko skopiował w większości pracę IBMa nad AIXem.
W każdym bądź razie w NetBSD przez długi czas brakowało menedżer woluminów logicznych. Tym bardziej, że trwają prace nad pobocznych projektem NetBSD Desktop (GNOME w standardzie etc).
może trochę niezwiązany z newsem komentarz, ale jeżeli staruje jakiś NetBSD desktop, to muszę o tym wiedzieć więcej, a tym bardziej jeśli gnome jest w standardzie ^^.
To co udało mnie się znaleźć:
http://wiki.netbsd.se/Desktop_Project
“WINE for WoW” lol
Za wszelkie inne przydatne informacje z góry dziękuję
Cenna informacja: “This page was last modified on 6 February 2009, at 22:25″. Czyli mniej-więcej wtedy, kiedy wymyślono “Desktop NetBSD”.
Od tamtego czasu strona już modyfikowana nie była, co daje jasny obraz “dynamiki projektu”.
To tylko strona główna, inne mają inne daty. Zapewne też stare, ale gwoli ścisłości należało naprostować…
RedHat kupił Sistinę z jej implementacją LVM, która bazowała na idei (nie kodzie) z HP, a HP swoje rozwiązania licencjonował od IBM. Nawiasem mówiąc, kod z IBM jest teraz dostępny jako EVMS.
Warto też wspomnieć, że RedHat kupił lvm1, teraz mamy lvm2
Dodać też należy że implementacja linux’owa jest daleko w tyle w porównaniu z aix’wą bądź hp-ux’ową
hint: bezpieczny lvreduce
A co jest niebezpiecznego w obecnym lvreduce?
A np. to że dla zamontowanych systemów plików jest to operacja wysoce niebezpieczna w odróżnieniu od implementacji aix bądź hp-ux gdzie działa bezboleśnie.
PS: Spróbuj zmniejszyć zamontowany system plików i będziesz wiedział dlaczego jest takie niebezpieczne.
Czyli jak w implementacji aiksa czy hp-ux udostepnie woluminy przez iSCSI i postawie na nich ext3, to moge te woluminy bez przeszkod zmniejszac – i ext3 samodzielnie sie dostosuje?
Nie wydaje mi sie.
Po prostu zasada dzialania jest inna. Linuksowy LVM to sa urzadzenia blokowe – LVM nie jest on zintegrowany z jednym jedynym systemem plikow, i mozna o tym przeczytac w dokumentacji (i rowniez o tym, jak uzywac lvreduce w sposob bezpieczny dla dowolnego sstemu plikow, ktory daje sie zmniejszac).
“Czyli jak w implementacji aiksa czy hp-ux udostepnie woluminy przez iSCSI i postawie na nich ext3, to moge te woluminy bez przeszkod zmniejszac – i ext3 samodzielnie sie dostosuje?”
Skupmy się na meritum
(nie nie zmniejszy się, ibm czy hp jasno pisze jakie fs są wspierane)
LVM zaimplementowany z systemi aix bądź hp-ux działa z natywnymi systemami plików owych systemów co w odróżnieniu od linux’a i jego natywnego systemu plików (ext2/3/4) już nie koniecznie. Poprostu chciałnym mieć działające lvreduce na chociaż jednym systemie plików w linux’ie.
PS: tylko nie udowadniaj że ext i jego ewolucję nie są natywnym systemem plików linux’a
Działaja zmniejszenie, tyle że nie online.
“Z powodów licencyjnych zespół NetBSD napisał własny sterownik na licencji BSD, który współpracuje z LVM na licencji GPL.”
Jak dla mnie te różnice licencyjne które uniemożliwiają szybki i jasny transfer kodu między wolnymi licencjami jest conajmniej smutny i spowalniający działania
Wprowadzanie kodu GPL do jądra na licencji BSD mija się z celem. Sprawa jest jeszcze bardziej poważna ze względu na fragmenty kodu systemu plików ZFS na licencji CDDL, z którą GPL kompatybliny nie jest.
Używanie kilku licencji w danym projekcie jest problematyczne i może wiązać się z problemami prawnymi.
W przypadku przestrzeni użytkownika powyższe ograniczenia praktycznie znikają. Być może zespół NetBSD przeniesie Linuksowy sterownik Device Mappera do wspomnianego RUMPa. Wtedy to użytkownik końcowy zdecyduje z czego chce korzystać.
Niby tak, ale z drugiej strony jest to cena za ochronę przed wykorzystaniem wolnego oprogramowania dla tworzenia zamkniętych “odgałęzień” zapewnianą przez copyleftowe licencje takie jak GPL czy CDDL. Cena, którą widać niektórzy są gotowi zapłacić.
@maciek: Praktyka pokazuje, ze taka “ochrona” nie jest potrzebna – jakos Postgres czy Xorg rozwijaja sie swietnie bez niej. Natomiast uniemozliwienie wykorzystania kodu na GPL przez projekty na innych licencjach daje sie odczuc caly czas.
Tak, zwłaszcza historia projektu Wine.
@krzabr: Gratuluje – wlasnie zrozumiales, co jest nie tak z licencja GPL.
Wiemy, wiemy. Nie pozwala żeby Apple za darmo wzięło czyjś kod…
A odczep się Ty od nieswojej pracy, co. Jak coś napiszesz to możesz wydać na jakiejkolwiek licencji. A od cudzego wara.
@bies: a to nie jest tak, że zły GPL bierze z BSD i nic nie daje? Chyba częściej taki argument padał u trasza.
Zawsze mnie fascynował ten Uniksowy system NetBSD, czytałem kiedyś że na nim właśnie testują najszybsze łącza internetowe. Dla mnie jednak jest zbyt trudny , aby na nim działać , może kiedyś jak wyjdzie ten Desktop Gnome BSD to opanuję z grubsza go , by potem przesiąść się na dłużej. Może już nie trzeba będzie emulować javy i flasha z Linuksa.
Zainwestuj w PCBSD tam większość rzeczy skonfigurujesz graficznie , lub jeśli chcesz mieć system łatwo konfigurowalny z konsoli to się pobaw w OpenBSD wbrew pozorom system nie jest trudny , a zainstalowanie sobie gnome z paczek nie jest trudną sprawą
Mi chodzi o coś innego . O to żeby można była bez problemu portować rozwiązania między wolnymi licencjami . Nie powinno być problemu że w systemie są elementy na licencjach BSD , GPL i np MPL . A jednak są i przez to powstają idiotyzmy typu pisanie na nowo sterownika na innej licencji a ten czas można spożytkować na inne potrzebne projekty .
Rozwiązaniem powinno być ochrona copyleftem odpowiednich fragmentów kodu użytego na innej licencji a nie nakaz pisania tego od początku
Właśnie rozchodzi się o to, że twórcy kodu na BSD nie chcą copyleftowej ochrony i z tego powodu kod na GPL nie może trafić do BSD.
Zespol NetBSD uzyl kodu GPL, gdzie mogl (userland). Wprowadzenie kodu GPL do jadra byloby rownowazne ze zmiana calego kodu jadra z licencji BSD na GPL. Nawet, jesli nie w calosci to ograniczenia uzycia kodu projektu zawsze wynikaja z najbardziej restrykcyjnej licencji.
Pytanie jaki jest sens wieloletniego programowania na licencji BSD i porzucenie tego z dnia na dzien? W jadrze NetBSD zapewne znajda sie fragmenty kodu np. na licencji MPL, LGPL czy CDDL. Zadna z tych licencji nie wymaga jednak mozliwosci wchloniecia pierwotnego kodu. I jak tu nie mowic o wirusowosci GPLu?
Widocznie GPL musi być gównianą licencją skoro posuwa się do metod wirusowości , nie od dziś wiadomo że gówno wciska się siłą lub daje się mu ładne opakowanie .
Nikt ci nie każe z niej korzystać, a chociaż z grzeczności uszanuj wybór tych, którzy zdecydowali się wydawać soft na GPL.
@krzabr: ja np. nie rozumiem ludzi (BSD-owców) którzy gotowi są oddać swój kod za darmo jakimś firmom które potencjalnie mogą zarobić na nim grube pieniądze. GPL daje mi pewność że przyczyniam się do rozwoju FLOSS a jednocześnie żadna firma nie będzie bezkarnie zarabiać na mojej pracy.
Nie rozumiem BSD-owców, ale to nie znaczy że ich nie szanuję. Jeżeli chcą utrzymać kod jądra na swojej licencji, przepisanie drivera jest najlepszym wyjściem. Gdybym to ja był autorem tego linuksowego sterownika, nie miałbym nic przeciw jego obecności w jądrze BSD, ale nie chciałbym też żeby za jego pośrednictwem został on użyty gdzieś w zamkniętym produkcie.
@vshader: Nie rozumiesz, bo pominales najistotniejszy szczegol: otoz tworzenie otwartego oprogramowania nie jest dla wiekszosci ludzi podstawowym celem w zyciu. Istotniejsze jest zarabianie kasy – a w przypadku oprogramowania na licencji BSD latwiej znalezc firme, ktora bedzie sklonna zainwestowac kase w rozwoj czegos innowacyjnego bazujacego na tym kodzie. W przypadku licencji GPL nawet gdyby ktorys z developerow chcial zalozyc taka firme, to i tak bedzie ograniczony przez GPL – w szczegolnosci, nie bedzie mogl swojego kodu zachowac dla siebie, bez rozdawania go calemu swiatu na licencji GPL.
@trasz: masz rację, ale tylko jeżeli dany kod jest tworzony z myślą o zarobku. Zauważ że jest wielu ludzi, którzy hobbistycznie (po godzinach) piszą całkiem spore projekty. W ich wypadku lepszą licencją jest GPL.
Poza tym, BSD, GPL i podobne są z zasady licencjami wolnego oprogramowania. Myślę, że jeżeli ktoś chce zarobić na swoim kodzie, lepiej niech od początku będzie on zamknięty. Jeżeli znajdzie się inwestor skłonny zainwestować w projekt, na pewno będzie bardziej zadowolony mając pewność że nikt inny na pewno nie zna/używa tego kodu.
@vshader: To, ze kod jest tworzony hobbystycznie, nie oznacza, ze nie nalezy uniemozliwiac innym placenia za niego. Jesli firma chce mi zaplacic w zwiazku z czyms, co zrobilem hobbystycznie – prosze bardzo. Tyle, ze w przypadku licencji GPL jest to mocno utrudnione, bo taka firma zaponsoruje nowa funkcjonalnosc calej swojej konkurencji.
Programiści piszący kod licencjonowany na GPL często nowe funkcje bądź modyfikacje piszą na zlecenie osób/firm zainteresowanych. Taki zleceniodawca może napisać własne funkcje zamykając je na swoim podwórku. W przypadku dużego projektu jak FreeBSD to nie problem. Jednak dla małego projektu to już spora strata. Przykładem rodzimym jest LMS.
Jest to mały projekt i gdyby każdy z użytkowników (głównie polskich) swoje poprawki zastawił dla siebie jego rozwój byłby znacznie wolniejszy.
Już nie raz pisałem że licencja BSD jest dla mnie licencją okradaną , natomiast nie podoba mi się w GPL że kod złaczony z tą licencją musi być gpl . Ochrona copyleftem jest dobra ale nie musi być tak drastyczna w przypadku łączenia z wolnymi licencjami przykład CDDL . Który chroni kod na tej licencji . I nie ma takich problemów przy łaczeniu go z BSD jak z GPL
I dokładnie o to chodzi. FreeBSD czy NetBSD nie ma problemów z integracją kodu na licencji LGPL, CDDL czy MPL (chociaż jeśli istnieje podobny na licencji BSD – wybór jest oczywisty). Natomiast czystego GPLa unikają jak diabeł wody święconej z wspomnianych wcześniej powodów. OpenBSD natomiast to odrębna sprawa.