On Wednesday June 8 2005 12:05 pm, prash wrote: > hello, > 1. why should i (and how can i) define a /tmp partition when i > don't know what temporary space each app might take? a dvd burner > might decide to take 4 gb, a regular app just 10 kb. if i go higher > it's a waste 95% of the time, lower and i risk some apps not > working well. (this is why i don't have a /tmp defined above: i > decided to let the app take how much ever it wanted out of / > (root)) This is an argument against /tmp being it's own filesystem. One somewhat common alternative is to dedicate space you would otherwise have allocated to /tmp to swap instead and use tmpfs for /tmp instead. A single partition system is best for newer users and machines that will be changing function somewhat unpredictably. A better solution would be one partition for everything and let it go for a few months to see what kind of usage you get. For best results, you should start watching disk usage a few weeks in advance of needing to repartition. This will give you a good idea what you're actually using. > 2. suppose i reduce the partition sizes of some of the folders > above and keep aside, let's say, 5gb of > "unpartitioned/empty/unused" space. can i later merge this space > with any other partition based on need? (for example if /usr/local > becomes larger than 18 gb - and friends who are aware of my > downloading skills know that that can happen - can i merge it with > this free 5 gb to make it 23 gb?) You can, but it's messy. -- Paul Johnson Email and Instant Messenger (Jabber): baloo@ursine.ca http://ursine.ca/~baloo/
Attachment:
pgppgEsmPtTaF.pgp
Description: PGP signature