Re: re-thinking partitions
- are symlinks really fast? Quite, except on NFS. could you be more specific? could you describe a situation where symlinks would slow-down things and a possible solution eliminating thesymlink? Normally, no NFS data is cached on the client, which means that for a small file, accessed via a symlink, the time to get the file will be twice, because the server will be contacted once to resolve the symlink, and a second time to access the file. This can get quite slow if you've got bad latency. Solution: don't use symlink forests on NFS exported volumes. why not have symlink resolving done by the server? AFAIK there's no need for the client to know about symlinks! Phil. -- Otavio Exel /\oo/\ [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: re-thinking partitions
On Mon, 17 Nov 1997 11:17:51 GMT Otavio Exel ([EMAIL PROTECTED] ) wrote: - are symlinks really fast? Quite, except on NFS. could you be more specific? could you describe a situation where symlinks would slow-down things and a possible solution eliminating thesymlink? Normally, no NFS data is cached on the client, which means that for a small file, accessed via a symlink, the time to get the file will be twice, because the server will be contacted once to resolve the symlink, and a second time to access the file. This can get quite slow if you've got bad latency. Solution: don't use symlink forests on NFS exported volumes. why not have symlink resolving done by the server? AFAIK there's no need for the client to know about symlinks! You probably don't want this: o you want to have readlink() o you don't want rm -r automatically follow symlinks on NFS partitions o etc... etc... This is not a good idea... Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
re-thinking partitions
hi everybody, I'm re-thinking my HD partitioning and would apreciate some advice! - are symlinks really fast? - I read somewhere that 500mb for /var and /tmp is fine; what exactly does that mean? two partitions summing up 500mb? one 500mb partition and symlinks from /var and /tmp? - why is /usr/tmp symlynked to ../var/tmp instead of /var/tmp? same applies to /usr/spool; is it important? - what will happen with hard lynks if I cp -d from one part to another? TIA! -- Otavio Exel /\oo/\ [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: re-thinking partitions
On Fri, 14 Nov 1997 10:24:10 -0200 Otavio Exel ([EMAIL PROTECTED] br) wrote: - are symlinks really fast? Quite, except on NFS. You really should worry about it unless you're a performance freak. - I read somewhere that 500mb for /var and /tmp is fine; what exactly does that mean? two partitions summing up 500mb? one 500mb partition and symlinks from /var and /tmp? This is a lot of space wasted unless you have large spool directories (news/mail). For a reasonable single-user station, 64MB should be largely enough on /var. /tmp is left to your choice (16 is a good number). - why is /usr/tmp symlynked to ../var/tmp instead of /var/tmp? same applies to /usr/spool; is it important? Yes, all symlinks should be relative, in case you mount filesystems across NFS or with a boot disk: let's say you have /dev/hda1 / /dev/hda2 /usr /dev/hda3 /var Then mounting them from the rescue disk, you would have: /dev/hda1 /mnt /dev/hda2 /mnt/usr /dev/hda3 /mnt/var And /mnt/usr/tmp would correctly point to /mnt/var/tmp instead of /var/tmp. - what will happen with hard lynks if I cp -d from one part to another? They'll get duplicated. -d applies only to symlinks. If you want to preserve files exactly, you want to use cp -a (or tar, cpio, etc...). Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: re-thinking partitions
Philippe Troin [EMAIL PROTECTED] writes: This is a lot of space wasted unless you have large spool directories (news/mail). For a reasonable single-user station, 64MB should be largely enough on /var. /tmp is left to your choice (16 is a good number). I would find 16M for /tmp WAY too small. I do development, and the compiler wants to put it's temporary files /tmp - some of them can be fairly large. Compiling with -pipe in g++ fixes this, and g++ does respect the $TMPDIR environment variable, but those solutions feel like kludges around the problem. My answer was to make /tmp a soft link onto a partition with a lot of space. (I do actually use -pipe by default, but I have a lot of RAM and not everyone does.) Later, Dale -- + finger for pgp public key -+ | Dale E. Martin | University of Cincinnati Savant Research Laboratory | | [EMAIL PROTECTED]| http://www.ececs.uc.edu/~dmartin | +--+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: re-thinking partitions
On 14 Nov 1997, Dale Martin wrote: Philippe Troin [EMAIL PROTECTED] writes: This is a lot of space wasted unless you have large spool directories (news/mail). For a reasonable single-user station, 64MB should be largely enough on /var. /tmp is left to your choice (16 is a good number). I would find 16M for /tmp WAY too small. I do development, and the compiler wants to put it's temporary files /tmp - some of them can be why not put /var and /tmp in the same root partition? /---/ Daniel J. Mashao Electrical Engineering[EMAIL PROTECTED] University of Cape Town http://www.ee.uct.ac.za/~daniel Rondebosch, 7700, S. Africa(w) 27+21+6502816 (h) 27+21+6863662 /---/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: re-thinking partitions
Daniel Mashao [EMAIL PROTECTED] writes: why not put /var and /tmp in the same root partition? When you run out of space on your root partition while compiling, it's a real pain. I've had it happen. I've never run out of space on /var, or on / if I don't have /tmp on it. So, I have /tmp soft linked to the partition with the most free space on my system. (This is a peculiarity of my environment, I know, but I still think that 16M is a tad small for /tmp, which is what I was originally responding to.) Later, Dale -- + finger for pgp public key -+ | Dale E. Martin | University of Cincinnati Savant Research Laboratory | | [EMAIL PROTECTED]| http://www.ececs.uc.edu/~dmartin | +--+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: re-thinking partitions
Daniel Mashao wrote: On 14 Nov 1997, Dale Martin wrote: Philippe Troin [EMAIL PROTECTED] writes: This is a lot of space wasted unless you have large spool directories (news/mail). For a reasonable single-user station, 64MB should be largely enough on /var. /tmp is left to your choice (16 is a good number). I would find 16M for /tmp WAY too small. I do development, and the compiler wants to put it's temporary files /tmp - some of them can be why not put /var and /tmp in the same root partition? basically because I was afraid symlinks could slow it down; but I'l do just that; create /dev/hda2/tmp and /dev/hda2/var and symlynk /tmp and /var there; thanks! /---/ Daniel J. Mashao Electrical Engineering[EMAIL PROTECTED] University of Cape Town http://www.ee.uct.ac.za/~daniel Rondebosch, 7700, S. Africa(w) 27+21+6502816 (h) 27+21+6863662 /---/ -- Otavio Exel /\oo/\ [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: re-thinking partitions
Dale Martin wrote: Daniel Mashao [EMAIL PROTECTED] writes: why not put /var and /tmp in the same root partition? When you run out of space on your root partition while compiling, it's a real pain. I've had it happen. I've never run out of space on /var, or on / if I don't have /tmp on it. So, I have /tmp soft linked to the partition with the most free space on my system. (This is a peculiarity of my environment, I know, but I still think that 16M is a tad small for /tmp, which is what I was originally responding to.) yes, all this partitioning stuff becomes not so important if you use symlinks; AFAIK the only true reason to avoid symlinking /var or /tmp into another partition is that /var and /tmp are more vulnerable to crashes on (say) power faillures; thanks! Later, Dale -- + finger for pgp public key -+ | Dale E. Martin | University of Cincinnati Savant Research Laboratory | | [EMAIL PROTECTED]| http://www.ececs.uc.edu/~dmartin | +--+ -- Otavio Exel /\oo/\ [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
