Page 31 of 55 FirstFirst ... 21262728293031323334353641 ... LastLast
Results 601 to 620 of 1081
Like Tree13Likes
  1. #601  
    So guys last night I did a TON of research on sysctl.conf and especially on old Android Devices (with ram and processor speeds similar to the Pre like the Hero)

    and I came up with these sysctl.conf settings:

    Code:
    vm.swappiness = 90
    vm.vfs_cache_pressure = 300
    vm.dirty_expire_centisecs = 1500
    vm.dirty_writeback_centisecs = 800
    vm.dirty_background_ratio = 5
    vm.dirty_ratio = 5
    vm.min_free_kbytes = 1024
    vm.oom_kill_allocating_task = 1
    vm.max_map_count = 32768
    vm.overcommit_memory = 0
    vm.page_cluster = 2
    vm.zone_reclaim_mode = 2
    kernel.shmmax = 268435456
    kernel.shmall = 16777216
    kernel.sched_latency_ns = 600000
    kernel.sched_min_granularity_ns = 400000
    kernel.sched_features = 24188
    Why each setting:

    vm.swappiness = 90

    This sets if the kernel perfers swap over memory for applications. Since we have limited memory, I believe its best to keep as much in swap as possible, according to linux documentation, this is true especially for devices that tend to sleep a lot. What sleeps more than background services on a phone thats mostly off in your pocket.

    vm.vfs_cache_pressure = 300

    On any system, RAM is used to cache files from the hard disk so that they load much faster. Notice how when you open an app the second time, it loads much faster? That is because it is cached in RAM. Unfortunately we dont have much RAM to spare, so we need to pressure the kernel to remove any cache on the RAM for files so that more is left for apps. Things might take a bit longer to load, but the trade off is more RAM, which is what we desperately need. Also, this was designed for spindle type hard drives that need to spin up and have fragmented files. On a non fragmented SSD like the Pre's 8gb memory, its not needed as much.


    vm.dirty_expire_centisecs = 1500

    This was confused a bit earlier in terms of what it does. It does not time how long pages are automatically put from Memory into Swap. What it does is like Cache Pressure above, determine how often cached data is cleared from the ram and put back on the SSD. This does not affect swap, but using it more often will clear up more RAM.

    vm.dirty_writeback_centisecs = 800

    Similar to above setting

    vm.dirty_background_ratio = 5
    vm.dirty_ratio = 5


    These two determine the ratio of how much RAM is used to cache dirty files. The percent is kept low because a) we dont need it as badly with an SSD, and b) we need all the ram we can. According at least to Android documentation, dirty data has nothing to do with pages for programs, but rather just files that are cached from the solid state disk onto RAM for fasters retrieval. In a perfect world, we would have tons of RAM to do this, but in our Pre-'s we do not.

    vm.min_free_kbytes = 1024


    Basically how much RAM must be kept free at all times, incase a program suddenly needs to request a large ammount of ram for one reason or another. The lower the number though, the more RAM the system can use. I like to live dangerously, so its put low. We need all the RAM we can get anyways. If your phone is locking though, id suspect its LunaManager running out of free ram due to this guy.

    vm.oom_kill_allocating_task = 1

    Determines how the kernel kills tasks that are taking up too much memory and locking the system up. This is more aggressive, so a program will just quit out rather than locking your whole phone up.

    vm.max_map_count = 32768

    How much memory in pages is mapped to each program. The default is 64556, but in reality I doubt a lot of apps use more than 32 mb of ram. If they are, then they are probably leaking and crashing the phone anyways.
    If a PDK app fails to start its probably this setting, so revert to default in that case.

    vm.overcommit_memory = 0

    How aggressive the kernel is at allowing programs to commit memory. This is the default but I am just making sure its set. LunaManager is set to 1, which is what we commented out in post 74, which has been debated to not have much effect but it couldnt hurt. Allowing a program to commit memory that doesnt exist in a RAM starved system sounds like a bad idea.

    vm.page_cluster = 4

    How many page files can be swapped from ram to swap at a given time. I think a larger number is better because a program that is locking the phone up can quickly be sent to swap or vice versa to solve the problem.

    vm.zone_reclaim_mode = 2

    How much memory can be reclaimed by the system. I set it to 2 which basically allows the kernel to dump dirty data to make room for new page files.

    kernel.shmmax = 268435456
    kernel.shmall = 16777216
    kernel.sched_latency_ns = 600000
    kernel.sched_min_granularity_ns = 400000
    kernel.sched_features = 24188


    These are Android kernel settings that apparently were modified by Google when they created Froyo. So this is what older Android phones with Pre 2.X Android use to speed up their system. I have no idea what they do...but hey if it works for older android phones maybe it will help us.

    I have my phone set to 128 mb compcache as well...I dont know what is the best, I think it is based on your needs.

    These settings probably work better with a larger swap file on the SSD, how is that coming along?
    Last edited by rmausser; 06/13/2011 at 12:25 PM.
  2. #602  
    Quote Originally Posted by rmausser View Post
    kernel.shmmax = 268435456
    kernel.shmall = 16777216
    kernel.sched_latency_ns = 600000
    kernel.sched_min_granularity_ns = 400000
    kernel.sched_features = 24188

    • kernel.shmmax: This value can be used to query and set the run time limit on the maximum shared memory segment size that can be created. Shared memory segments up to 1Gb are now supported in the kernel. This value defaults to SHMMAX.
    • kernel.shmall:This parameter sets the total amount of shared memory pages that can be used system wide. Hence, SHMALL should always be at least ceil(shmmax/PAGE_SIZE).


    The remaining sched_* things are irrelevant. Our kernels don't have that capability:

    Code:
    root@My Pre:/# find /proc -iname '*sched_*'
    /proc/sys/kernel/sched_compat_yield
    root@My Pre:/# find /sys -iname '*sched_*'
    root@My Pre:/#
    That one hit:


    • sched_compat_yield: With this tunable you can make sys_sched_yield() be more aggressive, by moving the yielding task to the last position in the rbtree. The default is 0 (what Ingo Molnar likes), and when you set it to 1 you get what Linux Torvalds proposes.


    I dunno. Personally, I'd probably go with Linus on this one. Palm has left it at default:0. Only you can decide, I guess. I'll set it to 1 and see what happens. I'd try and have to digest this to really understand the difference: Red-black tree - Wikipedia, the free encyclopedia


    I'm trying your settings, minus the ones that don't exist of course, to see what happens.


    • 14M ramzswap (no backing store)
    • 103M swap (REAL swap)
    • No over_commit


    #######
    # EDIT:

    One quick level of Angry Birds with the above (with the quick tweak from me).

    Code:
    swpd     free    buff    cache   si      so
    4904     7096    6760    69408   0       0
    4904     6736    6784    69328   0       0
    8912     1788    6740    68780   13      800
    18028    2024    3668    66144   6       1830
    24320    3344    1700    55100   0       647
    25292    4564    1832    52536   0       118
    25292    4504    1840    52536   0       0
    25292    3460    1848    52684   0       0
    25292    3196    1860    52772   0       0
    25292    2776    1868    52772   0       0
    25292    2836    1884    52772   0       0
    25292    2716    1884    52772   0       0
    25292    2656    1892    52772   0       0
    25292    42980   1900    53284   6       0
    25292    43656   1908    52680   0       0
    25276    44436   1920    52680   0       0
    (Delay is 5 seconds between lines).
    #######


    M.
    Last edited by Xanadu73; 06/13/2011 at 01:21 PM.
  3. #603  
    So I continued to play with the swap file thought. After a few failed attempts I was able to get my phone to mount the swap file.

    Code:
    root@Harry's Palm Pre:/var/home/root# dd if=/dev/zero of=/swapfile1 bs=1024 count=262144
    root@Harry's Palm Pre:/var/home/root# free -m
                 total       used       free     shared    buffers     cached
    Mem:           239        225         14          0          1         38
    -/+ buffers/cache:        185         54
    Swap:          199        102         97
    root@Harry's Palm Pre:/var/home/root# cd /media/internal
    root@Harry's Palm Pre:/media/internal# ls
    Backgrounds                  id_rsa.doc
    DCIM                         mountcfs.log
    Messaging                    prl.tar.gz
    Open Source Information.pdf  ramdump
    Palm Pre.mp4                 ringtones
    SoftSwapEvent                save_log
    appdata                      saverestore
    apps                         softswap
    downloads                    swapfile
    fstab                        wallpapers
    id_rsa                       webos-patches.log
    root@Harry's Palm Pre:/media/internal# mkswap /media/internal/swapfile 
    Setting up swapspace version 1, size = 262140 KiB
    no label, UUID=d5f5a127-42d1-4985-9360-95f1eae99b23
    root@Harry Anuszewski's Palm Pre:/media/internal# swapon /media/internal/swapfile 
    root@Harry's Palm Pre:/media/internal# free -m
                 total       used       free     shared    buffers     cached
    Mem:           239        237          2          0          2         41
    -/+ buffers/cache:        192         46
    Swap:          455        102        353
    root@Harry's Palm Pre:/media/internal#
    I was able to gain a few mb of swap. whether it will help or not is still unknown. the dd command was only writing at about 3.3mb a sec. not very fast at all. but it gives me something to play with.
    Sprint pre -> Motorola Photon 4G
  4. #604  
    Quote Originally Posted by theXfactor2011 View Post
    So I continued to play with the swap file thought. After a few failed attempts I was able to get my phone to mount the swap file.


    I was able to gain a few mb of swap. whether it will help or not is still unknown. the dd command was only writing at about 3.3mb a sec. not very fast at all. but it gives me something to play with.
    How does that compare to how the swap partition performs?
  5. carrel's Avatar
    Posts
    425 Posts
    Global Posts
    426 Global Posts
    #605  
    Quote Originally Posted by theXfactor2011 View Post
    I was able to gain a few mb of swap. whether it will help or not is still unknown. the dd command was only writing at about 3.3mb a sec. not very fast at all. but it gives me something to play with.
    Wow! Very cool. I have a few questions/comments...

    1) You say you gained a "few mb of swap". It looks to me that you gained 256 mb of swap. Is that what you meant when you said a "few"? I wasn't sure if you were referring to 256 as a few or if you thought it was less.

    2) In your "code" above, you are dd-ing to /swapfile1, but you are running mkswap and swapon on /media/internal/swapfile. How is that??

    3) What kernel are you running? I got kernel panics doing just what you did. I was running F104 (2.1.0). Maybe I'll try a different kernel if yours is different.
  6. #606  
    Quote Originally Posted by Unclevanya View Post
    How does that compare to how the swap partition performs?
    writing to the /dev/store/swap i got around 14 to 72 mb/s
    writing to the /media/internal i got around 2 to 5 mb/s

    a pretty big difference. Most likely due to the vFat partition on media/internal
    Sprint pre -> Motorola Photon 4G
  7. #607  
    Quote Originally Posted by carrel View Post
    1) You say you gained a "few mb of swap". It looks to me that you gained 256 mb of swap. Is that what you meant when you said a "few"? I wasn't sure if you were referring to 256 as a few or if you thought it was less.
    yeah i was referring to 256mb as a few more mb

    Quote Originally Posted by carrel View Post
    2) In your "code" above, you are dd-ing to /swapfile1, but you are running mkswap and swapon on /media/internal/swapfile. How is that??
    yeah i should correct that. When I was quoting I was following directions on a website. I copy and pasted everything except the dd part. I copied it from the website and pasted it and forgot to edit it. Here is the corrected command.
    Code:
    root@Harry's Palm Pre:/media/internal# dd if=/dev/zero of=/media/inte
    rnal/swapfile bs=1024 count=262144
    262144+0 records in
    262144+0 records out
    268435456 bytes (256.0MB) copied, 135.430664 seconds, 1.9MB/s
    root@Harry's Palm Pre:/media/internal# mkswap /media/internal/swapfile 
    Setting up swapspace version 1, size = 262140 KiB
    no label, UUID=c3856da7-d472-4109-91e6-38aa3f4357a5
    root@Harry's Palm Pre:/media/internal#

    Quote Originally Posted by carrel View Post
    3) What kernel are you running? I got kernel panics doing just what you did. I was running F104 (2.1.0). Maybe I'll try a different kernel if yours is different.
    im running the latest F105-68 kernel. I experienced a few crashes myself when trying to mount the swapfile. After running the command a few times it finally mounted. I have no clue what caused the crashes. I will say that until we find out why it crashes its not fully stable. Once its mounted I cant access the usb partition when I plug my phone into my computer. It does seem that once its mounted its stable and will be fine but mounting it is a challenge.
    Sprint pre -> Motorola Photon 4G
  8. #608  
    Hello,

    So I figured someone needed to try it. So i did. I have resized my swap partition and added an additional 256mb of space.

    Warning
    • I am not responsible for anything that happens
    • This may erase your phone
    • You may have to doctor
    • If you doctor in the future you will need to re partition again!
    • the world may come to an end... again
    • Again do this at your own risk


    Code:
    root@Harry's Palm Pre:/dev/store# lvm lvreduce -L 6.3G /dev/store/med
    ia
      Rounding up size to full physical extent 6.30 GB
      WARNING: Reducing active logical volume to 6.30 GB
      THIS MAY DESTROY YOUR DATA (filesystem etc.)
    Do you really want to reduce media? [y/n]: y
      Reducing logical volume media to 6.30 GB
      Logical volume media successfully resized
    root@Harry's Palm Pre:/dev/store# lvm lvresize /dev/store/swap -L +25
    6M
      Extending logical volume swap to 360.00 MB
      Logical volume swap successfully resized
    root@Harry's Palm Pre:/dev/store# mkswap /dev/store/swap
    Setting up swapspace version 1, size = 368636 KiB
    no label, UUID=0b7b9230-93ad-48ad-a1b0-b12e65d0fe55
    root@Harry's Palm Pre:/dev/store# swapon /dev/store/swap
    root@Harry's Palm Pre:/dev/store# swapon -s
    Filename				Type		Size	Used	Priority
    /dev/ramzswap0                          partition	98296	75344	100
    /dev/mapper/store-swap                  partition	368632	0	-1
    Quick steps
    • Backup the /media/internal (everything including hidden files)
    • Turn off the swap partition (swapoff /dev/store/swap)
    • unmount media (umount /dev/store/media) -not required but do it
    • lvm lvreduce -L 6.3G /dev/store/media and type y
    • lvm lvresize /dev/store/swap -L +256M
    • mkswap /dev/store/swap
    • swapon /dev/store/swap
    • reboot (brings back media and verifies settings stick)


    after I resized my files and everything were still in tack and readable. however I am only using 1.5 gb. if you are close to being full you should probably make some room.

    This will be much faster then the stupid swap file that keeps crashing people's phones. Remember to attempt at your own risk. If you phone explodes or goes crazy and eats your dog i am not responsible.

    Good luck
    Last edited by theXfactor2011; 06/13/2011 at 07:41 PM.
    Sprint pre -> Motorola Photon 4G
  9. #609  
    DUDE! You resized the swap!!!

    GOOD WORK! PROPS!!

    Going to do this right now.
  10. #610  
    Quote Originally Posted by theXfactor2011 View Post
    Hello,

    So I figured someone needed to try it. So i did. I have resized my swap partition and added an additional 256mb of space.
    It should probably be mentioned / stressed that should anyone that does this Doctors their phone in the future, they will need to do this again. The Doctor rewrites the partition information.
    Last edited by Xanadu73; 06/14/2011 at 10:08 AM.
  11. #611  
    Modified:

    Code:
    vm.swappiness = 90
    vm.vfs_cache_pressure = 300
    vm.dirty_expire_centisecs = 1500
    vm.dirty_writeback_centisecs = 800
    vm.dirty_background_ratio = 5
    vm.dirty_ratio = 5
    vm.min_free_kbytes = 1024
    vm.oom_kill_allocating_task = 1
    vm.max_map_count = 32768
    vm.overcommit_memory = 0
    vm.page_cluster = 2
    vm.zone_reclaim_mode = 2
    kernel.shmmax = 268435456
    kernel.shmall = 16777216
    sched_compat_yield = 1
    compact_memory = 1
    Added Compact memory, I am not sure if this is more for spindle disk swap files though, as SSD's do not fragment that much and can do non-sequential read/write. Couldnt hurt,imo we can afford CPU power, Ram we cannot.

    **EDIT**

    I am now running the above settings without compcache because my swap file is 256mb!!! Sweet
    Last edited by rmausser; 06/13/2011 at 07:34 PM.
  12. #612  
    Quote Originally Posted by Xanadu73 View Post
    It should probably be mentioned / stressed that should anyone that does this Doctors their phone in the future, thy will need to do this again. The Doctor rewrites the partition information.
    Good point. But since we are on 2.1 or at least most of us the chances of us having an ota is slim and once things get working, hopefully we wont need to doctor.
    Sprint pre -> Motorola Photon 4G
  13. #613  
    Quote Originally Posted by rmausser View Post
    Modified:

    Code:
    compact_memory = 1

    Yeah, we don't have that one available either. I went looking for that one too a while back (year or so) when I was very first looking into all this.

    Code:
    root@My Pre:/# find /proc -iname '*compact*'
    root@My Pre:/# find /sys -iname '*compact*'
    root@My Pre:/#
    So you don't need to bother putting that one in. As far as I can tell, it wasn't introduced until 2.6.29, we use 2.6.24.


    M.
    Last edited by Xanadu73; 06/13/2011 at 08:48 PM.
  14. carrel's Avatar
    Posts
    425 Posts
    Global Posts
    426 Global Posts
    #614  
    Quote Originally Posted by theXfactor2011 View Post
    Hello,

    So I figured someone needed to try it. So i did. I have resized my swap partition and added an additional 256mb of space.

    Warning
    • I am not responsible for anything that happens
    • This may erase your phone
    • You may have to doctor
    • If you doctor in the future you will need to re partition again!
    • the world may come to an end... again
    • Again do this at your own risk


    Code:
    root@Harry's Palm Pre:/dev/store# lvm lvreduce -L 6.3G /dev/store/med
    ia
      Rounding up size to full physical extent 6.30 GB
      WARNING: Reducing active logical volume to 6.30 GB
      THIS MAY DESTROY YOUR DATA (filesystem etc.)
    Do you really want to reduce media? [y/n]: y
      Reducing logical volume media to 6.30 GB
      Logical volume media successfully resized
    root@Harry's Palm Pre:/dev/store# lvm lvresize /dev/store/swap -L +25
    6M
      Extending logical volume swap to 360.00 MB
      Logical volume swap successfully resized
    root@Harry's Palm Pre:/dev/store# mkswap /dev/store/swap
    Setting up swapspace version 1, size = 368636 KiB
    no label, UUID=0b7b9230-93ad-48ad-a1b0-b12e65d0fe55
    root@Harry's Palm Pre:/dev/store# swapon /dev/store/swap
    root@Harry's Palm Pre:/dev/store# swapon -s
    Filename				Type		Size	Used	Priority
    /dev/ramzswap0                          partition	98296	75344	100
    /dev/mapper/store-swap                  partition	368632	0	-1
    Quick steps
    • Backup the /media/internal (everything including hidden files)
    • Turn off the swap partition (swapoff /dev/store/swap)
    • unmount media (umount /dev/store/media) -not required but do it
    • lvm lvreduce -L 6.3G /dev/store/media and type y
    • lvm lvresize /dev/store/swap -L +256M
    • mkswap /dev/store/swap
    • swapon /dev/store/swap
    • reboot (brings back media and verifies settings stick)


    after I resized my files and everything were still in tack and readable. however I am only using 1.5 gb. if you are close to being full you should probably make some room.

    This will be much faster then the stupid swap file that keeps crashing people's phones. Remember to attempt at your own risk. If you phone explodes or goes crazy and eats your dog i am not responsible.

    Good luck
    Uh.... How is your /media/internal still sane?? You resized the lvm, but did not resize the vfat partition on that lvm. I think you will run into file consistency problems in the future. Likely only if you get the partition close to full, but still, it should be resized. Find the size of the lvm in bytes and then you can use resizefat (included by Palm) to resize it.

    And how did you unmount /media/internal ??? I wasn't able to do that. I was calling umount with /media/internal. I'll try again with /dev/store/media. Did you run a "df" or "mount" after running that to see what was really unmounted. I'm away from home so I can't try it right this minute.

    Despite my skepticism about the sanity of your /media/internal partition, I have to say: Nice job! And you've got grande cajones! If you can make resizefat work, I will try it.

    Oh, one more thing... You shrank one partition by giving lvmreduce a fixed value and you resized the other by giving lvmresize a relative value. Why not use a relative value with lvmresize for both. So 'lvmresize -L -256M /dev/store/media' and 'lvmresize -L +256M /dev/store/swap' ?? I worry that you are leaving some disk unused since you removed more than 256M from media.
  15. #615  
    Quote Originally Posted by carrel View Post
    Uh.... How is your /media/internal still sane?? You resized the lvm, but did not resize the vfat partition on that lvm. I think you will run into file consistency problems in the future. Likely only if you get the partition close to full, but still, it should be resized. Find the size of the lvm in bytes and then you can use resizefat (included by Palm) to resize it.

    And how did you unmount /media/internal ??? I wasn't able to do that. I was calling umount with /media/internal. I'll try again with /dev/store/media. Did you run a "df" or "mount" after running that to see what was really unmounted. I'm away from home so I can't try it right this minute.

    Despite my skepticism about the sanity of your /media/internal partition, I have to say: Nice job! And you've got grande cajones! If you can make resizefat work, I will try it.

    Oh, one more thing... You shrank one partition by giving lvmreduce a fixed value and you resized the other by giving lvmresize a relative value. Why not use a relative value with lvmresize for both. So 'lvmresize -L -256M /dev/store/media' and 'lvmresize -L +256M /dev/store/swap' ?? I worry that you are leaving some disk unused since you removed more than 256M from media.
    to answer the first part my media/internal works fine. all the data is present even after the resize. I can check the partition size with lvdisplay. To be honest my commands leave 144mb of unused space between media/internal and swap. I could tweak that a bit but this is the first run and nobody else tried it. The main thing is/media/internal should be a link to /dev/store/media. all the dev file systems are included in the lvm. so when you thought you saw 8 gb free you really didnt or thats what i got out of it. lvm is shared between several partitions and can be moved / swapped around as needed. really great on palms part. Makes it very easy to change things without a complete over hall. I found that 8 partitions share the lvm.

    In the end nobody else has tried this and as far as i can tell i have a 369mb swap partition that nobody else has. I only have one pre for trail and error so Ill learn as i play around lol.
    Sprint pre -> Motorola Photon 4G
  16. #616  
    this is great... making some serious progress now. hopefully this can become fully baked into a easy method. Great Work. Keep us updated.
  17. #617  
    Quote Originally Posted by theXfactor2011 View Post
    to answer the first part my media/internal works fine. all the data is present even after the resize. I can check the partition size with lvdisplay.
    The point that is trying to be made is that no where did you tell the file systems themselves what their new size is. For instance, you didn't tell the vFAT's File Allocation Table that it is smaller. If you try and write past what the size is now (and it will let you because you didn't update it), one of three things will happen:


    • It'll gleefully let you write, but the files will never be available.
    • It'll gleefully write, but begin to over write things that are currently there due to the space not really being there (this includes installed apps, remember!).
    • It'll simply go boom.


    You didn't update the ext3 partition you "resized" either. The same things will happen there. Perhaps not as "severe" of situation like with stupid vFAT. Ext3 should just fall back to blow up (no space available and stop dead). Frankly, for the ext* partitions, going with ext3 was probably a dumb decision on Palm's part. They should've used ext4 (if they felt they really HAD to use an ext* FS...), or perhaps something even faster and more resilient like XFS. The best would probably be btrfs, but, I don't think that exists in 2.6.24, and I doubt it's back-portable. Not really sure on that one, though.

    "df" should show you that the partitions are still the old size.


    M.
    Last edited by Xanadu73; 06/14/2011 at 10:03 AM.
  18. carrel's Avatar
    Posts
    425 Posts
    Global Posts
    426 Global Posts
    #618  
    Quote Originally Posted by theXfactor2011 View Post
    to answer the first part my media/internal works fine. all the data is present even after the resize. I can check the partition size with lvdisplay. To be honest my commands leave 144mb of unused space between media/internal and swap. I could tweak that a bit but this is the first run and nobody else tried it. The main thing is/media/internal should be a link to /dev/store/media. all the dev file systems are included in the lvm. so when you thought you saw 8 gb free you really didnt or thats what i got out of it. lvm is shared between several partitions and can be moved / swapped around as needed. really great on palms part. Makes it very easy to change things without a complete over hall. I found that 8 partitions share the lvm.

    In the end nobody else has tried this and as far as i can tell i have a 369mb swap partition that nobody else has. I only have one pre for trail and error so Ill learn as i play around lol.
    Yes, LVMs are really cool and let you dynamically resize. BUT... what you are resizing is more akin to a logical disk. You still need to format that disk. The normal means to resize with LVMs is to resize the formatting first for resizing smaller and resize the formatting last for formatting larger. In essence that is what you did with swap. You ran mkswap after you did the lvmresize.

    Running resizefat is what the Doctor does when resizing /media/internal.
  19. carrel's Avatar
    Posts
    425 Posts
    Global Posts
    426 Global Posts
    #619  
    Quote Originally Posted by Xanadu73 View Post
    You didn't update the ext3 partition you "resized" either. The same things will happen there. Perhaps not as "severe" of situation like with stupid vFAT. Ext3 should just fall back to blow up (no space available and stop dead). Frankly, for the ext* partitions, going with ext3 was probably a dumb decision on Palm's part. They should've used ext4 (if they felt they really HAD to use an ext* FS...), or perhaps something even faster and more resilient like XFS. The best would probably be btrfs, but, I don't think that exists in 2.6.24, and I doubt it's back-portable. Not really sure on that one, though.

    "df" should show you that the partitions are still the old size.


    M.
    I agree with you that the partition table of media is now wrong, I don't think there is an ext3 partition involved. He only resized media, which is vfat, and swap, which is swap. And he did resize the "partition table" (it isn't really a partition table) of swap by using mkswap.

    If addition to using 'df' to look at the partitions, 'parted' could also be used.
  20. #620  
    Quote Originally Posted by carrel View Post
    I agree with you that the partition table of media is now wrong, I don't think there is an ext3 partition involved. He only resized media, which is vfat, and swap, which is swap. And he did resize the "partition table" (it isn't really a partition table) of swap by using mkswap.

    If addition to using 'df' to look at the partitions, 'parted' could also be used.

    It's kinda hard to decipher {code} blocks in mobile view... Yes, you are right, it looks like the only thing played with was /media/internal.


    M.

Posting Permissions