Partīcijas ar izmēru virs 2TB uz Linux

2009-02-02 18:43:32 UTC by maris in Noklusētā,

Manā rīcībā nonāca serveris ar ar 8TB diskiem no kuriem tika izveidots 5 raids, kā rezultātā tika iegūti 6.36TB datiem. Kā izveidot partīciju, kas ir lielāka nekā 2TB, jo tādi rīki kā fdisk,cfdisk,sfdisk to paveikt nevar un maksimālais partīcijas izmērs ko var izveidot ir 2TB. Problēma ir tur, ka augstāk minētie rīki neatbalsta GPT tabulu, bet gan novecojušo msdos partīciju tabulu, kas savukārt nav spējīga saprast lielākas partīcijas par 2TB. Risinājums ir parted, kas atbalsta GPT! 1. parted /dev/sdc 2. (parted) mklabel 3. New disk label type?  [msdos]? GPT 4. (parted) mkpart primary xfs 0 100% 5. (parted) name 1 data 7. (parted) set 1 lvm on Labojums: Gadījumā, ja pēc reboot partīcijas vairs nav, iespējamais iemesls var būt tas, ka kodolā nav "EFI GUID Partition support", pie viena ieslēdzam MSDOS partīciju atbalstu pretējā gadījumā parastās parīcijas nebūs pieejamas: File systems ---> Partition Types ---> [*] Advanced partition selection [*] EFI GUID Partition support [*] PC BIOS (MSDOS partition tables) support

(0 komentāri)

Acer un Empowering tolls

2009-02-01 09:28:51 UTC by Kristaps in Hardware, Software,

Nu jau nedaudz vairāk kā gadu atpakaļ manā pārvaldībā nonāca ACER Aspire 5720Z portatīvais dators. Tika uzstādīta Window XP operētājsistēma. Jau pēc dažu nedēļu lietošanas, tas mēdza vienkārši izslēgties, pie kam system logos nekas aizdomīgs netika manīts. Tā nu pagāja gads un šī datora izslēgšanās bija jau sasniegusi pat 3-6 reizes dienā. Tā kā visu laiku bija jāuzklausa to, ka dators neiet un tā un šitā, tad nu ņēmos meklēt problēmu. Nomainīju HDD, uzinstalēju operētājsistēmu, izgāju RAM testus u.t.t. Visi testi OK. Aizdomas uz pārkaršanu, taču pārbaudot kūlera darbību, viss liekas normāli. Meklēju garantijas dokumentus un prom uz garantiju. Servisā atdodu ar problēmu: "Izslēdzas". Otrā dienā saņemu zvanu, par to, ka dators ir gatavs un problēmas netika konstatētas. Kā man pavēstīja tālāk, tad stabila darbība Acer esot ar Windows Vista un EmPowering Tools. Tad nu meklēju Windows Vista un liku virsū ar EmPowering tūļiem. Nu jau pāris nedēļas problēmas nemanu. Kā reiz pēc šī visa, kādā pasākumā runājot par šo tēmu, uzzinu, ka šī problēma rodas, ja portāblis tiek iemidzināts, tad atmodinot, tam dzesēšanas darbība netiekot atjaunota un pārkaršanas rezultātā tas izslēdzas. Pēc neilga laika, arī darbā saņēmu Acer portatīvo ar šāda veida problēmu. Uzliku EmPowering tools priekš XP, bet par rezultātiem gan neko vēl nezinu. Cik esmu dzirdējies, ka arī tas uz XP īsti nestrādā. Te links uz lapu, kur pieejami dažādi draiveri acer portatīvajiem un galda datoriem, gan Windows XP, gan Vista operētājsistēmām. Ja kāds grib patestēt EmPowering Tolls uz XP, te links. Par rezultātiem, vai pieredzi, var padalīties komentāros .

(3 komentāri)

ReiserFSv3 vs XFS / reliability

2009-01-30 08:26:15 UTC by maris in Linux,

Failu sistēmas uzticība, drošums ir svarīgākais faktors misijai kritiskas aplikācijas darbības nodrošināšanā. Tādēļ ir vienmēr jāparedz iespējamos riskus. Protams, ir regulāri jāveic backup (automatizēti) un monitorings, bet arī tas nepasargā no daļējiem datu zudumiem. Liela nozīme ir tieši failu sistēmai, šajā gadījumā svarīgākais faktors failu sistēmas izvēlē ir tās drošums. Pēdējā laikā no daudziem kolēģiem un draugiem dzirdēju saucienus par to cik "kruts" esot XFS un no dažiem arī par to, ka reiserfs ir "gļukains". Kam es pilnībā nepiekrītu. Runājot par "gļukainību", tad tā ir tikai dzelžu vaina. Bet par pārējo nedaudz zemāk. Nolēmu veikt nelielu testu datu atjaunošanā (repair/recovery) uz XFS un ReiserFS v3 partīcijām. Tests:

    nullēju pirmos 4096b, mēģinu montēt, ja nesanāk, tad mēģinu atjaunot ar recovery tooļiem
    nullēju pirmos 4MB, mēģinu montēt, ja nesanāk, tad mēģinu atjaunot ar recovery tooļiem
Sāku ar XFS: mkfs.xfs /dev/vgd/test-xfs dd if=/dev/zero of=/dev/vgd/test-xfs bs=4096 count=1 xfs_repair /dev/vgd/test-xfs Uzmontēt neizdevās, tā kā tika nonullēts superbloks, tika palaists xfs_repair, kā rezultātā superbloks tika atjaunots no backup superbloka un nekas netika iemests iekš lost+found, kas nozīmē, kā xfs gadījumā var tikt pazaudēti pirmie 4KB. Reiserfs: mkreiserfs /dev/vgd/test-xfs dd if=/dev/zero of=/dev/vgd/test-xfs bs=4096 count=1 Partīcija tika uzmontēta bez recovery. Līdzīgi iepriekšējiem 4KB tika nonullēti 4MB, pēc kā XFS vairs nespēja atjaunot direktoriju koku un sagrūda visus datus iekš lost+found :( bad! Ar ReiserFS viss beidzās daudz labāk, ar reiserfsck --rebuild-sb reiserfsck --rebuild-tree --scan-whole-partition tika atjaunots superbloks un atjaunota direktoriju struktūra, iekrita arī daži faili iekš lost+found :) good! Lai padarītu šo pasākumu interesantāku nonesu pirmos 10MB, un arī tad struktūra tika atjaunota ar dažiem failiem iekš lost+found. Pēc šiem vienkāršajiem testiem mans spriedums ir: Reiserfs ir daudz uzticamāka nekā XFS. Jo šāda tipa corruption var notikt, ja uz diska vienā brīdi sarodas bad-blocks, protams kas arī ir jāmonitorē. Secinājums: izmantot reiserfs

(5 komentāri)

gmail sāk iekļauties RBL'os

2009-01-20 11:14:21 UTC by maris in Internets,

Viens no googles izejošajiem serveriem ticis iekļauts psbl melnajā sarakstā! Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554 5.7.1 Service unavailable; Client host [209.85.218.33] blocked using psbl.surriel.com; Listed in PSBL, see http://psbl.surriel.com/listing?ip=209.85.218.33 (state 14). atliek gaidīt, kad google aizvērs publiskos SMTP.

(0 komentāri)

Ceļu Policija kā odi pirms sprāgšanas

2008-12-16 20:34:24 UTC by maris in life,

Pāris dienas atpakaļ sanāca viens gadījums, kurā piedalījās mūsu "kārtības un drošības sargi". No rīta ap 10.00 braucu uz darbu - gar zemitānu tiltu, tad pārkārtojos uz zemitāna tilta 3. joslu, jo vēlāk bija jāveic kreisais pagrieziens uz Pērnavas ielu. Iekārtojos rindā uz nogriešanos, tad iedegās zaļais, pēc kā krustojumā izbrauca 4 mašīnas, es biju 4. paliekot uz gājēju pārejas, un tiklīdz iedegās dzeltenais tā arī visi aizbraucām no krustojuma. Nākamajā krustojumā, kas ir simts metrus tālāk, mani apturēja ceļu policija, biju domājis, ka kārtēja dokumentu pārbaude, kas pēdējā laikā man gadījās visai bieži, izrādījās, ka biju pārkāpis CSN, kas aizliedz kustību pie aizliedzošā signāla. Pēc kā sniedzu policistam savus paskaidrojumus, par to ka biju izbraucis krustojumā, pēc kā policists sazinājās ar savu kolēģi, kurš pateica, ka esmu bijis 15-20 metrus pirms stop līnijas, kā arī pateica to, ka viss ir fiksēts uz video, mani turpmākie paskaidrojumi tika ignorēti un policists devās uz savu dienesta automobili sastādīt protokolu! Kad viņš atnesa man protokolu un lika to parakstīt, es viņam lūdzu noskatīties video, uz ko saņēmu atbildi, ka 2 nedēļu laikā, lai ierodos "Gaujas 15". Un viss.. Tikko esmu no "Gaujas 15", nosēdēju tur pusotru stundu, rinda izrādījās samēra gara, tad pienāca mana kārta. Inspektors, kas izskatīja manu lietu, man paskaidroja, ka protokolā video nav minēts, kā arī nav minēts tas, ka pārkāpumu ir fiksējis viņa kolēģis nevis policists kurš to ir sastādījis, bet tieši tāpēc arī neparakstīju! Inspektors pateica, ka ir divas iespējas, vai nu parakstīt viņa protokolu un saņemt minimālo sodu, vai arī nākamajā dienā nākt ar iesniegumu, kas būtu par pamatu, lai šis liek rakstīt policistam dienesta ziņojumu, kā rezultātā es dabūtu maksimālo sodu - es parakstīju, pēc kā inspektors man palūdz protokola apakšā uzrakstīt, ka atzīstu savu vainu, no kā es atteicos. Un kā lai man pierādīt savu taisnību, ja policijai vienmēr ir taisnība. Šobrīd šiem ļaudīm ir pienākuši grūti laiki un dirsu tie plēš ne pa jokam, lai saglabāt savu darbu un nesūdīgo ienākuma avotu. Bet kāpēc to nedarīt nemuļķojot citus? Šai situācijai redzu vienu izeju - pārsūdzēt lēmumu tiesā, jo man ir liecinieks, kas ar mani brauca un var izklāstīt notikušo un policista teikto, kā arī pierādījumu neesamība no policijas puses.

(0 komentāri)