[08:29] geirha: det er vel sektor for sektor, ikke byte for byte...? [08:52] geirha: Hei. Det driver faktisk på enda. Men det ser ut til å gå mye seinere nå enn det gjorde til å begynne med. Men det driver på, ja. [08:52] Royk: Ja. Som sagt :) [08:53] RoyK: Startet i går kl. 2215. [08:59] bjorn1000: en harddisk er omtrent dobbelt så rask på begynnelsen (dvs ytterst på skiva) siden det er cirka dobbelt så mange sektorer der som innerst... [08:59] bbl [09:02] RoyK: Nuuuvel. Det forklarer saken :)) [10:49] bjorn1000: hvor stor har bilde.img blitt? [11:01] RoyK: Det står ikke her. Står at errsize=143 MB, og den har funnet 3774 feil. [11:04] I en ny terminal: «ls -lh /mnt/royk» [11:30] geirha: http://paste.ubuntu.com/746919/ [11:31] Oi, 63 GiB av ... 400-noe GiB [11:31] Det tok lenger tid enn forventet :/ [11:31] 1227 @dennis │ ehm. folk lo da den falt ut. det ble IKKE "god stemning" [11:31] argh, misclick [11:31] orsak. [11:32] Men, har du sagt A, må du si B ... eller er det Å? [11:32] Hva falt ut? [11:33] dildo, ut av ein sekk [11:34] what?! [11:34] han sa først "det vart god stemning då den falt ut" [11:34] lett å tolke det feil, så 1227 var ein korreksjon til det [11:37] Ah. Haha [11:39] PST vil visst kriminalisere "thought-crime" http://www.aftenposten.no/meninger/Heksejakt-p-terrortanker-6704662.html [12:40] * blaamann endret Ctrl-delete til delete for å flytte filer i Nautilus til Trash [13:39] Status: http://paste.ubuntu.com/747024/ [13:48] Vil det være et problem å ha maskinen på i en uke i strekk? [13:48] bjorn1000: Du prøver å redde disk? [13:50] Han har en døende ekstern disk på 500GB [13:51] 64G på ~17 timer [13:53] auda [13:53] Med dd_rescue? [13:53] usb1 ? [13:54] Nei, GNU ddrescue [13:54] Ja, fra en USB disk til en annen [13:54] :-/ [13:54] Ja, det er dd_rescue. [13:54] Er det GNU? [13:54] Eller, vet ikke om det er usb1 [13:54] Over USB1? heh [13:54] 11Mbit! [13:55] Berge: https://help.ubuntu.com/community/DataRecovery#Imaging_a_damaged_device.2C_filesystem_or_drive [13:55] geirha: åh, det er forskjell? [13:55] Jeg tenkte på den som er pakket i ddrescue, og binæren heter dd_rescue. [13:56] Kjekt at det finnes en moderne GNU-variant. [13:56] Vet ikke hva forskjellen er, men vi installerte gddrescue [13:57] kanskje en idé å sjekke om det er usb1 uansett [13:59] ddrescue-kommandoen vi kjører skal kunne avbrytes og fortsettes senere, så det bør være mulig å flytte diskene til en maskin som har raskere usb. [14:00] ...etter at man har bekreftet at det faktisk er usb1. Selv hadde jeg også overført til en egen interndisk, og ikke en annen usbdisk [14:01] Den interne var på 160GB eller noe [14:10] Berge: iirc er dd_rescue != gnu ddrescue [14:10] s/iirc/svjv/ :P [14:11] RoyK: Ja, jeg fant ut det. [14:20] k [14:30] Royk / geirha / Kagee - Det er usb2. Har ikke usb3. http://paste.ubuntu.com/747067/ [14:31] uff - ting tar visst tid... [14:31] bjorn1000: med så mye feil, spørs det om det hadde gått så mye raskere med usb3 [14:32] Den forsøker vel å lese de samme sektorene igjen og igjen. [14:32] RoyK - Sånn er livet. Ingen tvil om at gamle-disken sliter. Ja, men jeg har ikke USB3. Den leser vel sektorene 3 ganger, med den kommandoen vi har gitt. [14:32] jau - er vel bare å la den holde på... [14:32] RoyK: Jepp [14:32] bjorn1000: Alle, ikke bare de den feiler på? [14:32] Ja, kjører med -r 3. Hadde kanskje vært en ide og kjøre over disken én gang først. [14:32] bjorn1000: i tillegg kommer det at diskkontrolleren sannsynligvis prøver flere ganger den også [14:33] Samma det - reddes det som reddes kan. [14:33] Nei, den prøver bare igjen på de som feiler, den må da være såpass smart. :) [14:33] bjorn1000: det kan ta noen dager, men når du er ferdig, sitter du i hvert fall igjen med noe som bør være det beste du kan få uten å sende den til IBAS eller tilsvarende [14:34] Hvis og når dette går i boks, får dere tenke ut hvem eller hva som fortjener en donasjon, i og med at IBAS går tomhendt. [14:35] Jeg tar gjerne en donasjon av alle pornobildene du klarer å redde [14:35] bjorn1000: du bør i hvert fall se på muligheten til å sette opp noe i speil/raid neste gang [14:36] RoyK: Jeg antar at bjorn1000 har lært leksen om sikkerhetskopi nå (-: [14:36] (RAID er ikke sikkerhetskopi.) [14:36] nei, men det er veldig fint mot disker som ryker... [14:37] * RoyK skulle ønske det fantes et vettugt filsystem med snapshot-støtte på linux [14:38] lvm? [14:38] "vettugt"? [14:38] lvm-snapshotting er bak mål [14:38] Hva er galt med lvm? [14:38] Hvorfor det? [14:39] for hvert snapshot, legger du til én i/o-operasjon for hver write/modify [14:39] geirha: Eh, NEI. Det vil du ikke, muæhh hæhh hæhh hæhhh! :DDD [14:39] RoyK: Og det gjør du ikke for andre COW-snapshotsystemer? [14:40] bjorn1000: ikke med zfs, f.eks. - der skrives endringene til et nytt sted og en peker oppdateres [14:40] heller ikke btrfs [14:40] Du må fortsatt slå opp pekeren en eller annen retning. [14:40] men btrfs != vettugt så lenge det ikke er flagga stabilt (og så lenge det mangler fsck) [14:40] Berge: For så vidt, men jeg er IKKE dårlig på sikkerhetskopier, egentlig. Men joda. Enda bedre, vil jeg nok bli. [14:40] RoyK: Tror det har fått fsck i helt nye versjoner! [14:40] Berge: det er LITT forskjell på å endre en peker og å utføre en i/o-operasjon x ganger [14:40] Berge: nei [14:40] btrfs er jo et takras av prioriteringer. [14:40] RoyK: Åh, kanskje det bare var snakk om. [14:41] bjorn1000: Du er åpenbart ikke flink nok? (-: [14:41] det har vært snakk om det i drøyt to år [14:41] bjorn1000: Sånn all den tid du bruker energi på å redde data her. [14:41] Berge: Nei. Umulig å være uenig i det :/ [14:42] Berge: med zfs og ~100 snapshots av et filsystem, er i/o til det filsystemet som i/o til et filsystem uten snapshots... [14:42] RoyK: Folk jobber visst med lvm-redirect-problemet også: https://github.com/jthornber/linux-2.6/blob/thin-stable/Documentation/device-mapper/thin-provisioning.txt [14:42] Berge: med zfs og noen tusen snapshots, tar det opp mer minne, men det er det... [14:42] RoyK: Med ZFS dør ytelsen din på Linux uansett, siden du må bruke FUSE. [14:42] Så du må ut og inn av userland for hver bidige operasjon. [14:43] Berge: uansett synes jeg snapshotting bør være i filsystemet og ikke på blokk-laget [14:43] RoyK: Jeg er litt agnostisk der. [14:43] litt greit at metadata er konsistent med snapshots [14:43] Tror jeg. [14:43] Det er fordeler og ulemper med begge deler. [14:43] med lvm er snapshot async if forhold til metadata [14:43] dvs du aner ikke hvor mye du får med [14:43] Eksempelvis får du vesentlig mindre kompleks filsystemkode. ext[234] er tross alt dødelig stabile greier. [14:44] Og du får df som gir mening (= [14:44] Berge: tviler litt på at noen "hooks" for å tillate sync-snapshotting ville gått ut over stabiliteten... [14:44] RoyK: Det er litt mer komplekst enn som så i virkeligheten. [14:45] Det tok ganske mange år for ZFS å bli noe i nærheten av modent.- [14:45] Og Sun kastet _mye_ penger og flinke folk på det. [14:48] Berge: jada - prøver ikke å si at det er enkelt - bare sier at lvm snap ikke er liv laga [14:49] RoyK: Tja. [14:49] Det er fint for veldig mange ting. [14:49] Om du skal ha _masse_ ytelse, går du jo uansett ikke for ZFS eller noe annet med snapshoting. [14:49] Og det ser ut til at man forsøker å fikse litt på LVM: [14:49] s/:/.7 [14:50] Berge: atte... som sagt - om du har ett snapshot på LVM, så dobler du antall IOPS for skriveoperasjoner, om du har to snapshots, tredobler du IOPS osv [14:50] Berge: om du mener det er akseptabelt, har du en litt annen virkelighetsoppfatning enn det jeg har [14:50] RoyK: Det kommer som sagt an på usecaset. [14:50] nei, det gjør ikke det... [14:50] Jeg har egentlig sjeldent behov for snapshoting generelt, så jeg ser ikke helt fascinasjonen. [14:51] Jeg har brukt det for å teste virtuelle maskiner fra tid til annen (og ha en kjent state å gå tilbake til), men det føltes verken kjappere eller treigere. [14:51] Berge: om du har brukt snapshotting i praksis, ville du nok hatt et litt annet syn på det :) [14:51] Antagelig fordi overheadet i å virtualisere et helt system eter opp en ekstra IOPS eller to. [14:51] RoyK: Vel, ja, men jeg sier altså at LVM er helt fint for en del use cases. [14:51] Og at ZFS (for ikke å snakke om btrfs) har sine problemer. [14:51] Hva bruker du snapshoting til? (-: [14:51] Berge: jeg har 50TB+ med snapshotting hvert 10. minutt, hver time osv og legger tilbake data fra backup (dvs ikke snaps) svææææææææært skjelden [14:52] Berge: hvilke problemer er det du sikter til med ZFS? [14:52] RoyK: Ytelse, spesielt på Linux. [14:52] ja, men så kjører jeg ikke zfs-fuse :P [14:52] fuse har ytelsesproblemer [14:52] Men da kjøre du ikke linux. [14:52] ikke til zfs-lagring, nei... [14:53] Nei, og da snakker vi jo overhodet ikke om det samme (-: [14:53] av samme grunn som at jeg ikke kjører IIS/.net på linux [14:53] Jeg løser dette ved å ikke kjøre IIS. [14:53] eller banker inn spiker med skrutrekker... [14:53] Og ikke bruke BSD. [14:53] (-: [14:53] Men hva bruker du snapshoting til? [14:53] kall det gjerne sanntidsbackup [14:54] Av hva? [14:54] noen sletter en katalog med et lass med drit, så ligger det i snapshottet [14:54] git ^___^ :-P [14:54] kan ikke bruke git/svn/hg/etc for brukerdata... [14:54] Det finnes en rekke måter å få til ca-sanntidssikkerhetskopier som ikke er på filsystemnivå, avhengig av hva man gjør. [14:55] jadajada - jeg sier bare at snapshotting er MYE lettere enn alt det andre ;) [14:55] RoyK: Jeg er ikke uenig, jeg bare lurer på når det er _nyttig_ (-: [14:55] det er _alltid_ nyttig [14:55] Nei. [14:55] Det er det altså ikke. [14:55] neivel [14:55] fortell [14:56] Og verdien av å kjøre Linux er ganske høy for meg, så selv om det er nyttig fra tid til annen, skal det litt til for å bli nyttig nok til at det er verdt det å bruke en BSD eller Solaris. [14:56] når er det snapshotting ikke er nyttig? [14:56] RoyK: Eh, det er du som har bevisbyrden her, ikke jeg (-: [14:56] du kommer med en påstand... [14:56] Nei, du gjør. [14:56] Utgangspunktet er vel ordinære filsystemer? [14:56] Og så mener du at snapshoting er nyttig. (Hvilket jeg er enig i, for noen tilfeller.) [14:57] med unntak av databaser og andre ting der prosesser må stoppes for at de lagrede dataene skal være verdt noe, er snapshotting alltid gunstig [14:57] det blir som å ha en backup parat til enhver tid [14:57] Databaser har jeg ekte sanntidsbackup av. [14:58] Det takler de på applikasjonslaget, og _vesentlig_ mer elegant enn noen filsystemvariant ville gjøre. [14:58] jeg lurer fremdeles på når snapshotting ikke vil være gunstig........ [14:58] Det eter plass? [14:58] ja, det gjør backup også [14:58] Ja, men på andre disker og filsystemer. Og en del mindre. [14:58] så kan du sette snapshottinga til kun å gjelde f.eks. siste uke eller måned [14:58] Det er sikkert kjekt å ha kopi av alle sine data hvert tiende minutt bakover, men disk er også kjekt. [14:59] Berge: du minner meg om de over 60 på jobb som ikke vil ha snapshotting for å kunne ha enerett på restore fra tape ;) [14:59] RoyK: Eh, jeg forsvarer ikke tape. [14:59] Jeg sier at jeg lever veldig fint uten snapshoting, og at du ikke er overbevisende i at det er så nyttig (= [15:00] Som sagt, det har sin misjon både her og der. [15:00] Berge: de vi kjører er hvert 10. minutt, så hver time, så hvert døgn, så hver uke osv... de fleste filsystemer fylles med nye data og folk sletter skjelden, så snapshotting bruker mindre plass enn du skulle tro [15:00] med mindre du begynner å snapshotte spoolingområder... [15:02] Om ZFS hadde vært i Linux, hadde jeg kanskje vært mer interessert. [15:03] eller btrfs? [15:03] Om btrfs hadde vært i nærheten av ferdig, kanskje. (-: [15:03] Kan man kun splitte screen horisontalt ? [15:03] Kagee: Ja. [15:03] :-/ [15:04] Kagee: Det finnes patcher som lar deg splitt vertikalt, og konkurrenten tmux har alle bjellene og fløytene. [15:04] Berge, såvidt jeg forstår, er btrfs i seg selv klart til bruk, bortsett fra at hvis noe går galt, så er verktøyene for å rette opp ikke gode nok enda. :) [15:04] To learn tmux or not to learn tmux [15:04] jo-erlend: Et filsystem uten fsck er overhodet ikke klart til bruk. [15:04] Kagee: Jeg lar være å splitte vinduer. (-: [15:04] Berge: er det noen andre grunner til å skifte ? [15:05] Kagee: Aner ikke, jeg bruker screen. [15:05] RoyK: Ellers er ordskiftet ditt med ASOR på bloggen din kostelig (-: (Gitt at det er din blogg, selvsagt.) [15:05] Berge, hehe, neida. Poenget var at istedenfor å snakke om _hvis_ ZFS _hadde vært_ i Linux, så går det an å snakke om _når_ btrfs blir klart for bruk :) [15:05] Enklere å kjøre samme screen i to terminaler. Da kan du flytte dem rundt som du vil. [15:06] jo-erlend: Nei, det er et stort hvis. (-: [15:06] Berge, å? [15:06] jo-erlend: Jeg stoler ikke på utviklingsprosessen. [15:06] interessant. Er det noen grunn til det? [15:06] Så jeg forholder meg rolig til de mest åpenbare manglene er løst. [15:07] Prioriteringene er ganske bak mål (-: btrfs har liksom prioritert integrert RAID-støtte og online derfrag før fsck. [15:07] (Som om moderne filssytemer trenger defrag. Og med moderne mener jeg… ext2.) [15:08] df virket i lang, lang tid ikke (-: [15:08] Men inline lzo-komprimering var der fra starten. [15:08] Det er litt å først implementere alle de kule tingene, og så ta alle de viktige tingene. [15:09] Berge: viser seg at screen har fått det, med C-a | [15:09] Kagee: wow, moderne [15:09] Kagee: Kanskje de tok inn patchene (-: [15:09] Quite possible. [15:16] Nå vil jeg bare ha valg av splittet terminal ved klikk på musa [15:16] * Kagee er kravstor i dag [15:22] Kjør samme screen i to terminaler ... [15:22] da må de være like store ? [15:22] Kun hvis de skal se samme vindu samtidig [15:23] screen -S "Min screen" i ene terminalen og screen -x "Min screen" i andre terminalen, så er du i gang. [15:27] Berge: hehe - ja, det er min blogg :) [15:30] Berge: forresten - http://zfsonlinux.org/ - det er native zfs for linux - men vet ikke hvor langt det har kommet... [15:35] Hrm, USN burde komme i noe mer strukturert formt. [15:35] format [15:35] http://www.google.pl/ :) [15:35] usn? [15:35] Et 4 GB stor svn-tree. Vell. Jippi... [15:36] RoyK: Ubuntu Security Notices. [15:36] Som kommer på web og epost. [15:36] Og jeg tenkte jeg skulle parse dem litt. [15:36] Men nei. [15:44] Berge: har du et eksempel? [15:44] * RoyK har litt tid til overs for å prøve seg på litt perl-pelling [15:45] RoyK: http://www.ubuntu.com/usn/ for RSS- og Atom-strømmene. Det kommer også på epost. [15:45] Men jeg fant https://wiki.ubuntu.com/SecurityTeam/Specifications/USNSpec [15:45] Så jeg får håpe de holder seg til det, og lage en halvstødig parser. [15:45] RoyK: Jeg kan perle selv (-: [15:45] prøv på perl-pelling (og - anvend absolutt aldri allitterasjoner...) [15:47] Berge: kommer den i tekstformat også, eller må man tygge unna html-koden først? [15:47] RoyK: I epost kommer de i tekstformat. [15:47] Berge: kan du videresende en til meg? [15:47] http://dpaste.com/660844/ [15:47] Jeg kan også bounce. [15:47] De kommer med litt PGP-signering og mailman-footer og sånt. [15:48] Har du en epostadresse? [15:48] Berge: tror du finner den på bloggen min :P - men - roy ætt karlsbakk dått net [15:49] boingboing [15:49] Mulig du fikk med litt headere fra arbeidsplassen min. [16:04] skal vi se... må få testa zfs4linux her :) [16:04] men ... zfs har fremdeles ikke bpr, så det er ikke på langt nær så fleksibelt som md... [16:06] men... http://pastebin.ubuntu.com/747189/ <-- greit å ha zfs som sikkerhet med en sånn pool... [16:10] RoyK: ah, det finnes en http://usn.ubuntu.com/usn-db/database.pickle [16:14] hva er det? [16:14] $ file database.pickle [16:14] database.pickle: 8086 relocatable (Microsoft) [16:15] En python-serialiseringsgreier. [16:15] og hvordan leser man den? [16:16] Med python, skulle man tro. [16:16] Eller Python::Serialise::Pickle. [16:16] ja... men... hvordan... :þ [16:16] Jeg kan vel ikke python, jeg må slå det opp (-: [16:17] http://docs.python.org/library/pickle.html [16:23] Berge: http://pastie.org/2909618 [16:23] noko slikt [16:29] RoyK: Du er treig, jeg holder på å skrive JSON-parser i perl. (-: Det ble http://dpaste.com/660867/ i python. [16:29] I ordinær pythonstil er det suppetreigt. [16:30] ./dump-pickle.py > usn.json 7,32s user 0,18s system 81% cpu 9,227 total [16:30] (Altså, jeg skriver ikke en JSON-parser i perl. Sånn om noen lurte.) [17:44] n6en taster g5r fe53 når 1eg s2r5ver, etter 6**dater5ng 5 dag, hva s21er? [17:45] westernanalog: beklager, kan du prøve å gjenta ? [17:46] Jeg vet det er vanskelig å skrive på touch-tastatur på telefoner, men setningen din er uleselig. [17:46] tastat4ret er f4c2ed [17:46] westernanalog: sitter du på en laptop ? [17:46] 1a [17:46] yes [17:47] westernanalog: Det ser ut som om du har aktivert talltastatuert. Talltastene er gjerne skrevet med liten blå skrift på tastene [17:47] Prøv å skru av num lock eller lignende taster du har for å aktivere den delen av tastaturet på maskina. [17:49] takk [17:49] men jeg har garantert ikke aktivert det selv [17:49] så, hva var "6**dater5ng" ? [17:50] Ubuntu har så vidt jeg vet ikke mulighet til å aktivere den funksjonen. Iallefall ikke dersom mer enn num lock trengs. [17:50] oppdatering [17:51] mulig jeg har gjort enctrl alt delete og kommet borti funksjonstasten [17:52] 6**dater5ng=oppdatering [17:52] da lærte jeg noe nytt i dag og :) [17:53] takk for hjelpen [18:06] Berge: http://search.cpan.org/search?mode=all&query=json [18:06] RoyK: use JSON; [18:06] * RoyK lurer på hva Berge snakker om med python og suppe treigt... [18:07] Å dumpe pickle-databasen til JSON. [18:08] python er vel ikke nevneverdig treigere enn perl? [18:08] * RoyK trodde i hvert fall det gikk ut på det samme [18:43] det er ikke helt usant at 11.10 er heit. [19:00] 2hihi [21:28] geirha / RoyK: Neidasååååå. Men jeg bare lar det dure og gå, jeg. Snart natta igjen, jo. http://paste.ubuntu.com/747543/ [21:28] Blir man auto-loggaut herfra? Fikk ikke svar på det i går, og nå var jeg plutselig inaktiv igjen. [21:50] bjorn1000: Nei, du datt ut fordi internettilkoblinga datt ut. [22:12] geirha: OK. BBL. http://paste.ubuntu.com/747584/ [22:24] Kan noen hjelpe meg med en sed for å fjerne alle * mellom < og > ? [22:31] Må det være sed? [22:32] vel, jeg skal bruke det i vim :-P [22:32] Gfdxh ewq*rfi isfvf i framtida, klikk på *følgjande link: [22:32] JEg skulle fjernet *, men bare der * er innenfor [22:39] :%s/$*]*$\*/\1/ [22:39] Den vil fjerne én * [22:43] Usikker på hvordan du får gjort det med alle. Regulære uttrykk er ikke så veldig egnet til det der.