Portál AbcLinuxu, 15. června 2024 01:56
Zrychlování SATA. Ext3 pre-alokace založená na rezervaci. Správa SCSI ovladače atp870u. Správcovství BTTV. Porušení GPL firmou Tritton Technologies.
Do konference přišlo celkem 1986 emailů, nejvíce jich poslali Andrea Arcangeli, Andrew Morton a Jamie Lokier.
27. bře - 3. dub
Jeff Garzik napsal:
Funkce "lba48" v ATA umožňuje adresovat sektory > 137GB, a také přenosy až 64K sektorů namísto 256 sektorů ve starším ATA.
libata prostě omezilo všechny přenosy na 200 sektorů (pod tou hranicí 256 sektorů). To bylo hlavně kvůli opatrnosti a také jsem chtěl mít řešení, které funguje všude. Také jsem chtěl vědět, jak se ukáže iommu S/G.
Vypadá to docela dobře, takže je načase zapnout přenosy s velikostí lba48. Většina SATA disků bude z tohoto a dalších důvodů stejně lba48 - i těch menších než 137GB.
S tímto jednoduchým patchem se maximální velikost požadavku zvýší ze 128K na 32MB... takže vám může být jasné, že to určitě pomůže výkonu. Zvýší se propustnost. Sníží se počet přerušení. Zábava pro celou rodinu.
Přiložený patch je pouze pro jádra 2.6.x. Měl by být aplikovatelný na 2.6.5-rc2 a pozdější, včetně posledního mého patche 2.6-libata z kernel.org. Měl by to být celkem neškodný patch, ale nedá se předvídat, co se může stát, když ten kohoutek otevřete naplno. Bylo by fajn to otestovat v -mm :).
Hledá se dobrovolník, který vytvoří backport tohoto patche a pošle jej do linux-ide@vger.kernel.org - já jej pak začlením do mé fronty pro 2.4 libata.
Stefan Smietanowski se zeptal: Co se stane, když bude PATA disk ležet za Marvel bridgem - jak tomu je dnes u většiny SATA disků? A Jeff odpověděl: Větší přenosy s PATA fungují také. U bridgů je obecně lepší nastavit omezení na UDMA/100 (udma), ale větší přenosy jdou také. Stefan se ještě zeptal: A jsou v SATA LBA48 přenosy skutečně povinné? A Jeff odpověděl:
Ano i ne, v tomto pořadí :). SATA nevyžaduje lba48, ale je velmi nepravděpodobné, že bys narazil na SATA disk bez lba48.
Tak jako tak, libata podporuje to, co podporuje disk. Starší disky fungují bez problémů.
Na jiném místě poznamenal Nick Piggin, že maximální velikost požadavku 32M je příliš velká. Dodal: Vsadím se, že zisk se začne po asi 1MB rapidně zmenšovat. Jeff nesouhlasil; řekl, že jeho implementace prostě exportuje maximální hodnoty hardwaru a je na administrátorovi systému, aby pro daný stroj zavedl vhodná pravidla rozvrhu práce disku [disk scheduling]. Následovala dlouhá diskuze, ve které mimo jiné Andrea Arcangeli vyjádřil souhlas s tím, že překročení hranice 1MB nepřinese žádné výrazné zlepšení.
Jeff víceméně souhlasil, ale řekl:
Chci říci, že existují dvě maxima:
1) hardwarový limit
2) limit, který "dává smysl", např. 512k nebo 1M ve většině případů
Ovladač by se měl starat pouze o #1 a měl by být "zpraven" o #2.
Později dodal: Myslím, že délka této diskuze jasně ukazuje, že nízkoúrovňový ovladač by o nastavení té hodnoty neměl rozhodovat. Jens Axboe připojil:
Tady je rychlý patch, který se pokouší upravit hodnotu podle posledních dokončených požadavků. Změní ->max_sectors na hardwarový limit a přidá ->optimal_sectors, který odpovídá největšímu volanému IO cíli. Je rozdělen na READ (čtení) a WRITE (zápis). Snahou je udržet dobu provádění požadavku pod BLK_IORATE_TARGET, který je v tomto patchi 50ms.
Jens pak vyjmenoval ještě několik věcí, které jeho narychlo spíchnutý patch opomíjel.
Jeff a ostatní byli rádi, že někdo s něčím takovým přišel a pokračovali v diskuzi o dalších technických aspektech věci.
30. bře - 5. dub
Mingming Cao řekl:
Ext3 prealokace teď není k dispozici. Tohle je první prototyp ext3 prealokace založené na rezervaci - podle nápadů Andrewa a Teda. Ta implementace není kompletní, ale rád bych znal váš názor na současný design.
V této verzi prototypu už mám:
Jednotlivé body pak Mingming rozebral podrobněji a Andrew Morton odpověděl:
Myslím, že to směřuje správnou cestou.
Kromě jiného pak Andrew ještě navrhl přidat parametr pro "mount", který by tu funkčnost povolil (s výchozí hodnotou "off" (vypnuto)). Mingming poslal upravený patch a ještě se mluvilo o různých technických záležitostech.
4. dub - 7. dub
Stuart Longland se zeptal, kdo je správcem ovladače atp870u SCSI, protože nedávno získal PCI ACARD SCSI kartu a ta vypisuje při použití chyby. Marcelo Tosatti odpověděl: Oficiálně to vlastně nikdo nespravuje. James Bottomley a Doug Ledford udělali několik oprav pro v2.6, takže možná kontaktuj přímo je.
5. dub
Luis Miguel napsal: Mám údaje o nové kartě založené na bttv 878. Myslím, že by měla být zařazena do databáze karet, aby mohla začít fungovat. Kdo teď ten ovladač spravuje? Gerd Knorr odpověděl, že právě on.
7. dub
Roy Franz napsal:
Narazil jsem na prodejce, který prodává zařízení využívající upravený linuxový kernel, a který odmítá poskytnout zdrojový kód upraveného jádra. Tvrdí, že na jejich změny se GPL nevztahuje. Nezdá se, že by používali moduly. Nevím, co s tím dál, takže na to upozorňuji vývojáře jádra.
Jedná se Tritton Technologies NAS120. (Nabízejí i verzi s funkčností routeru, která je založena stejné desce.) Ta deska je založena na procesuru Toshiba TX39 (MIPS) a má na sobě ethernetový chip Realtek. Běží na tom kernel verze 2.4.16.
Viz: http://www.trittontechnologies.com/products.html
Vyrábí to zjevně mct.com.tw: http://www.mct.com.tw/prod/sa-100.html, protože některé soubory to tak označují.
Několik dalších prodejců prodává podobné verze téhož. http://www.iogear.com/main.php?loc=product&product_id=645 a http://www.claxan.ch/de/prod_det.asp?PRODID=CL-SA110&TOPNAVID=-1 (claxan nabízí nějaký zdrojový kód ke stažení, ale ne jádro. Jejich zákazník je kontaktoval a i oni odmítají dát zdrojové kódy jádra k dispozici.)
Následuje odpověď z Trittonu, ve které říkají, že upravené zdrojové kódy jádra nedají k dispozici. Následovalo to po několika vyměněných emailech, ve kterých jsem velmi srozumitelně říkal, že mám zájem o zdrojové kódy jádra.
Citovaný email od technické podpory:
Dříve jsem řekl, že jádro bude součástí balení. Ačkoliv to i nadále platí, buďte srozuměn s tím, že úpravy provedené v jádru tam obsaženy nebudou. Kvůli dvěma důvodům: 1) Ty úpravy nespadají pod GPL a 2) Vlastní je Toshiba.
Matthias Urlichs odpověděl: Upozornil bych je na to, že se jim dostane velkého množství negativní reklamy. A Erik Andersen dodal: Přidal jsem NAS120 do BusyBox Hall of Shame...
V originálu Kernel Traffic 260 vyšla navíc ještě tato témata:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.