Reiser5 ett filsystem under utveckling integrerar stöd för parallell skalning

Reiserfs

Edward shishkin är en utvecklare som har varit ansvarig för underhåll av Reiser4-filsystemstöd under det senaste decenniet för nya kärnversioner. Även om systemet har underhållits, till skillnad från andra filsystem som har avancerat i sin utveckling. Edward Shishkin arbetade i underhållet av Reiser4 och samtidigt arbetar jag med utveckling för Reiser5-filsystemet som redan den är tillgänglig för testning.

Denna nya version av Reiser5 sticker ut för att inkludera innovation i parallell skalning, som inte utförs på blocknivå utan via filsystemet.

Som en fördel av detta tillvägagångssätt, icke-parallella FS + RAID / LVM- och FS-paket förklaras fria från inneboende nackdelar (ZFS, Btrfs), som ledigt utrymme problem, prestanda sjunker när du fyller volym över 70%, föråldrade logiska volym designalgoritmer (RAID / LVM), tillåter dig inte att effektivt distribuera data på en volymlogisk.

I en parallell FS, innan den lägger till en enhet i en logisk volym, måste den formateras med standardmkfs-verktyget.

Till skillnad från ZFS implementerar Reiser5 inte sitt eget blocklager, även om den använder en gratis blockalloker O (1). Det är möjligt att komponera på ett enkelt och effektivt sätte en logisk volym från blockenheter av olika storlekar och bandbredd. Uppgifterna distribueras mellan dessa enheter med hjälp av nya algoritmer.

I tillkännagivandet av denna testversion Edward Shishkin kommenterade:

Det gläder mig att tillkännage en ny metod för att lägga till blockenheter till logiska volymer på en lokal maskin.

Jag tycker att det är en kvalitativt ny nivå i utvecklingen av filsystem (och operativsystem): lokala volymer med parallell skalning ...

I vårt tillvägagångssätt görs horisontell skalning med hjälp av filsystem snarare än medel för blocklager. Användaren kontrollerar flödet av I / O-förfrågningar som utfärdas för varje enhet ...

Som Edward Shishkin kommenterar: en del av I / O-förfrågningarna riktade till varje enhet är lika med dess relativa kapacitet tilldelad av användarenså att den logiska volymen fylls med data "jämnt" och "rättvist".

Samtidigt får blockenheter med lägre kapacitet färre block för lagring och enheter med lägre prestanda blir inte en flaskhals (som till exempel i RAID-arrays).

Att lägga till en enhet i volymen och ta bort enheten från volymen åtföljs av en ombalansering som bevarar "rättvisa" distributionen.

Alla inkluderade blockenheter kan underhållas samtidigt på den logiska volymen med hjälp av en individuell metod för var och en av dem (defragmentera för hårddiskar, posta bortkastningsfrågor för SSD, etc.).

Ledigt utrymme på en logisk volym kontrolleras av standardverktyget df (1). Dessutom har användaren möjlighet att övervaka ledigt utrymme på varje komponent i den logiska volymenheten.

Betydande framsteg i horisontell skalning gjordes med hjälp av den parallella nätverksfilen (GPFS, Luster, etc.). Det var dock inte klart hur man skulle ansöka
dina tekniker till en lokal FS.

Främst beror det på att i en lokal fil system har inte så mycket lyx som "backend-lagring" som nätverk dom gör. Vad den lokala FS har är ett extremt dåligt gränssnitt för interaktion med blockskiktet. Till exempel på lokal Linux FS kan du bara skriva och utfärda en I / O-begäran mot någon buffert.

Bland de saker som fortfarande finns i TODO-listan över Reiser5 är:

  • FSCK-uppgradering för att stödja logiska volymer
  • Asymmetrisk LV med mer än ett metadatablock per volym
  • symmetriska logiska volymer
  • 3D-ögonblicksbilder av LV
  • Fördelning av metadata över flera delvolymer
  • Kontrollera / återställ logiska volymer med hjälp av fsck-verktyget (uppgradering från tidigare version)
  • Globala volymer (nätverk), lägga till enheter på olika maskiner.

Om du vill veta mer om det kan du rådfråga följande länk. 


Lämna din kommentar

Din e-postadress kommer inte att publiceras. Obligatoriska fält är markerade med *

*

*

  1. Ansvarig för data: AB Internet Networks 2008 SL
  2. Syftet med uppgifterna: Kontrollera skräppost, kommentarhantering.
  3. Legitimering: Ditt samtycke
  4. Kommunikation av uppgifterna: Uppgifterna kommer inte att kommuniceras till tredje part förutom enligt laglig skyldighet.
  5. Datalagring: databas värd för Occentus Networks (EU)
  6. Rättigheter: När som helst kan du begränsa, återställa och radera din information.

  1.   luix sade

    Wow, jag trodde att reser hade dött efter Hans ..