| === fenris-_ is now known as ejat | ||
| excalibr | helo | 08:13 |
|---|---|---|
| ejat | elop | 08:13 |
| === smng is now known as sweemeng | ||
| excalibr | hello peeps..what's cracking | 13:51 |
| angch | nothin' | 13:56 |
| excalibr | angch ada guna lvm tak..is there any reason why one should avoid using lvm? | 14:04 |
| angch | excalibr, ada. why not lvm: single disk solution, no need extra complicated stuff. why lvm: more than one disk. | 14:05 |
| angch | Non technical reasons to use lvm: pass LPI101. | 14:06 |
| excalibr | haha..im not linux professional by any stretch of imagination..saje nak tinker tinker :P | 14:15 |
| angch | How to use LVM in real life: sudo palimpsest | 14:16 |
| excalibr | resizing partition containing data is really pita sometimes..that's what got me thinking into tryng lvm | 14:17 |
| angch | excalibr, ? | 14:17 |
| angch | How to resize partitions: sudo palimpsest | 14:17 |
| angch | wait. palimpsest doesn't have resizeing | 14:18 |
| angch | meh. lvm doesn't save you from resizing hell anyway. | 14:19 |
| angch | even more work. | 14:19 |
| angch | resize the vg, etc, then need to resize the actual fs. | 14:19 |
| angch | you want btrfs if you want some easier stuff | 14:19 |
| excalibr | btrfs dah stable enough ke | 14:20 |
| angch | excalibr, cukup stabil untuk Kagesenshi | 14:20 |
| excalibr | hehe | 14:20 |
| angch | personal saya tak berani nak guna. | 14:21 |
| angch | personally | 14:21 |
| angch | last time kena data loss sebab ada compression dan disk full. | 14:21 |
| angch | compression = tak dapat est disk free dengan tepat bila nak copy files. | 14:21 |
| excalibr | which data you lost? one that was being copied? | 14:24 |
| angch | forgot. was testing on scratch monkey anyway. | 14:24 |
| angch | (aka not real data) | 14:25 |
| angch | i don't put critical stuff on btrfs, unlike *some* other people. | 14:25 |
| * angch boring. use stable stuff. | 14:26 | |
| angch | ext4, 12.04lts | 14:26 |
| excalibr | stable is nice but a little bleeding edge doesn't hurt :p | 14:39 |
| angch | excalibr, said the person restoring stuff from backup after production server got nuked. | 14:40 |
| excalibr | hahaha | 14:41 |
| excalibr | angch: back to psl resizing partition, i always wonder why expanding linux partition can take forever to complete..like the other day i threw few gigs at the begining of a partition then waited almost 2 hours for the entire data in the partition to be shifted to near the begining of the partition..why does it even need to do that | 14:52 |
| angch | probably because the fs can grow and appended to, but you add stuff to start of block, you need to shift them. *all*. | 14:53 |
| angch | same reason as a coder/sysadmin you can easily append ( e.g. using >> ) to the tail of a file. | 14:54 |
| angch | you add stuff to beginning of file, you rewrite entire contents of file. | 14:54 |
| angch | so if you have 2 partitions A/B. and you delete B and grow A to cover B, it's fast. | 14:54 |
| angch | delete A and grow B = delete A, move B to A, then grow B. | 14:55 |
| angch | the move B to A is slow. | 14:55 |
| excalibr | yea..the fs obviously need to be expanded to cover the new area but why data need to be shifted..can't they stays where they are..i dont need remember having to go through this sort of hassle with windows part | 15:00 |
| excalibr | so even using lvm wont be able to save me from this resizing hell? | 15:02 |
| angch | excalibr, duh. | 15:02 |
| angch | don't do that then. | 15:03 |
| * angch don't understand people's need for resizing. | 15:03 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!