Re: [LUGOS] MySQL na CF ali kdo ve preveč o datote čnih sistemih
On Wed, 10 Oct 2007 12:34:02 +0200 Miha Tomšič [EMAIL PROTECTED] wrote: Hojla! Takole gre reč. Na sistemu, kjer je Compact Flash nadomestek za IDE disk, bi radi poganjali MySQL. Silite v težave. Vzamite bolj moderen cf card, so hitrosti boljše. Kako je z zanesljivostjo, ne vem, nimam praktičnih izkušenj. Boš moral verjeti proizvajalcu. Poglejte si jffs in jffs2, mislim pa da obstaja še nekaj fsjev, namenjenih CFju. -- Jure Pečar http://jure.pecar.org ___ lugos-list mailing list lugos-list@lugos.si http://liste2.lugos.si/cgi-bin/mailman/listinfo/lugos-list
Re: [LUGOS] MySQL na CF ali kdo ve preveč o datote čnih sistemih
Hojla! On 10/10/07, Jure Pečar [EMAIL PROTECTED] wrote: Takole gre reč. Na sistemu, kjer je Compact Flash nadomestek za IDE disk, bi radi poganjali MySQL. Silite v težave. Temu se reče dodana vrednost ;) Vzamite bolj moderen cf card, so hitrosti boljše. Kako je z zanesljivostjo, ne vem, nimam praktičnih izkušenj. Boš moral verjeti proizvajalcu. Proizvajalcu že zaupamo, ampak kako izkoristiti to, kar vemo. Mrbit bo pa treba svoj storage engine napisat... :) Poglejte si jffs in jffs2, mislim pa da obstaja še nekaj fsjev, namenjenih CFju. To je popular misconception. JFFS2 je namenjen flash napravam, do katerih imaš surovi dostop, CF je ferari med flashi, ker ima v svojem ohišju cel kontroler za flash in že dela to, kar ponuja tudi jffs2 za surove naprave: wear-leveling. JFFS2 na CF/IDE sploh ne dela. Posebna verzija CF-ja ponuja sistem SiSMART, ki šteje, kolikokrat je bil posamezen blok zbrisan in napisan - za informacijo, kako utrujen je CF. Srečno, M. ___ lugos-list mailing list lugos-list@lugos.si http://liste2.lugos.si/cgi-bin/mailman/listinfo/lugos-list
Re: [LUGOS] MySQL na CF ali kdo ve preveč o datote čnih sistemih
Pozdrav, Miha Tomšič wrote: najboljših primerih 6/4MB/s R/W - nekaširan) in da ima CF omejen rok trajanja - pri industrijskih CF-jih cca. 2miljona brisanj in pisanj na 128KB blok. 128KB je ogromno. Si prepričan, da je to najmanjša enota, ki jo lahko CF naslavlja? Moj 64-megabajtni CF je velik 64225280 bajtov ali (prosto po cfdisku, sfdiska žal nimam) 124992 sektorjev. Če to dvoje zdeliš, dobiš približno 512 bajtov na sektor, kar je najbrž standard za vse ATA naprave. Postavlja pa se vprašanje, ali CF samo navzven glumi teh 512 bajtov na sektor in interno uporablja kaj več/manj ali pa je to res to. A ima kdokakšne konkreten nasvet, kako natjunati datotečni sistem, da se bodo bloki CF-ja ujemali z bloki FS-ja ali je to default? man mkfs.ext2 pravi takole: OPTIONS -b block-size Specify the size of blocks in bytes. Valid block size vales are 1024, 2048 and 4096 bytes per block. If omitted, mke2fs block- size is heuristically determined by the file system size and the expected usage of the filesystem (see the -T option). If block- size is negative, then mke2fs will use heuristics to determine the appropriate block size, with the constraint that the block size will be at least block-size bytes. This is useful for cer- tain hardware devices which require that the blocksize be a mul- tiple of 2k. Mogoče lahko poskusiš z negativno vrednostjo, pa da mkfs to sam pogrunta. Resnično pa dvomim, da ti bo naredil datotečni sistem s 128 KB velikimi bloki. Kako prepričati MySQL, da piše vedno v 128KB blokih (ki se seveda ujemajo s CF-jevimi bloki)? Ali MySQL zapisuje celo datoteko ali dodaja na konec? Od nekod mi je ostalo v spominu, da lahko neko relacijsko bazo (pozabil katero) naščuvaš nad surovo particijo (/dev/hdaX) in tako zaobideš datotečni sistem. Če se to da, potem se najbrž da igračkati tudi z velikostmi blokov. LP, U. ___ lugos-list mailing list lugos-list@lugos.si http://liste2.lugos.si/cgi-bin/mailman/listinfo/lugos-list
Re: [LUGOS] MySQL na CF ali kdo ve preveč o datote čnih sistemih
Hojla! On 10/10/07, Uroš Golja [EMAIL PROTECTED] wrote: 128KB je ogromno. Si prepričan, da je to najmanjša enota, ki jo lahko CF naslavlja? Moj 64-megabajtni CF je velik 64225280 bajtov ali (prosto po cfdisku, sfdiska žal nimam) 124992 sektorjev. Če to dvoje zdeliš, dobiš približno 512 bajtov na sektor, kar je najbrž standard za vse ATA naprave. Postavlja pa se vprašanje, ali CF samo navzven glumi teh 512 bajtov na sektor in interno uporablja kaj več/manj ali pa je to res to. 128K je precej, ja. Ampak tako je. 2KB je page (z ECC in stuff), 128KB je pa cel blok, ki se briše/piše. Mogoče lahko poskusiš z negativno vrednostjo, pa da mkfs to sam pogrunta. Resnično pa dvomim, da ti bo naredil datotečni sistem s 128 KB velikimi bloki. Saj mene ne zanimajo tako veliki bloki. Želim si le, da se blok in inodi lepo zložijo v en blok CF-ja. Ker ko se mi posodablja datoteka, se mi posodobi še njen inode table. Rad bi samo zminimiziral število blokov, ki doživijo pretes ob vsakem pisanju na CF. Od nekod mi je ostalo v spominu, da lahko neko relacijsko bazo (pozabil katero) naščuvaš nad surovo particijo (/dev/hdaX) in tako zaobideš datotečni sistem. Če se to da, potem se najbrž da igračkati tudi z velikostmi blokov. To ima Oracle, kolikor je meni znano. Srečno, Mikka ___ lugos-list mailing list lugos-list@lugos.si http://liste2.lugos.si/cgi-bin/mailman/listinfo/lugos-list
Re: [LUGOS] MySQL na CF ali kdo ve preveč o datote čnih sistemih
On Wed, 10 Oct 2007 16:38:55 +0200 Miha Tomšič [EMAIL PROTECTED] wrote: Od nekod mi je ostalo v spominu, da lahko neko relacijsko bazo (pozabil katero) naščuvaš nad surovo particijo (/dev/hdaX) in tako zaobideš datotečni sistem. Če se to da, potem se najbrž da igračkati tudi z velikostmi blokov. To ima Oracle, kolikor je meni znano. innodb pravtako, pa verjetno postgres tudi. -- Jure Pečar http://jure.pecar.org/ ___ lugos-list mailing list lugos-list@lugos.si http://liste2.lugos.si/cgi-bin/mailman/listinfo/lugos-list
