Specifically for /tmp:
- Should ln -s /var/tmp /tmp?
In the case of a complete in-memory disk image (think "live boot CD") this might be acceptable, as every byte of RAM needs to be squeezed. Otherwise, unless you are hard-pressed for disk space, no. /var has its own peculiarities and mixing /tmp with /var/tmp may have unintended consequences when performing systems maintenance. It also adds an extra dependency in that /tmp must be mounted for /var/tmp to function properly; not everything needs /tmp and you may have a situation where you want to migrate it to a different partition or drive, but can't, because you don't want to unmount /var.
- Should /tmp be preserved between reboots or not?
No. If you are relying on this as a consistent behavior then you will, sooner or later, encounter issues.
- Should /tmp be on a real disk area or allowed to be implemented basically on the SWAP area (or tmpfs)?
When it's heavily used, this is a temptation - "we'll put /tmp into a RAM disk, it'll speed up access, and when the system reboots/shuts down, there's nothing to clean up". However, if you are thinking of implementing temp space as a RAM disk that will be swapped, then I would consider the ramifications of your system's swap space usage by other programs. If swap is there as a form of "emergency overflow" for when the system is in dire straights and needs it, the last thing you need is to have swap space consumed by a runaway process filling /tmp, consuming memory, causing pressure on the VM subsystem to swap to disk. Between swap activity, and the additional I/O streaming into the RAM disk (which in turn may cause additional page-ins to satisfy a seek() ) your system will quickly become I/O bound.
- Should /tmp be on a different disk from the / (root) disk?
Preferably, yes, although it's not necessary. If you make heavy use of it, or have a constant workload that requires it, then definitely yes. Hypothetical example: a database that dumps temp files to /tmp would gain a slight speedup by introducing /tmp to a separate spindle (ie. drive).
- Would you place /tmp on a different disk controller from the / (root) disk?
If you have a requirements for recoverability or speed, then it should be considered.
- Any rules of thumb for the size of /tmp?
It should accomodate 2x your expected workload. By this, I mean that if you have local users regularly using this space, sooner or later someone will do something silly and attempt to fill it up. Having a slight overage will allow you to avoid strange "issues" with programs that stop because their temp files have filled up what space is left.
If this is a "common services" installation, where the server provides one or more network services, but does not host users, then this will probably be on the low side. If this is a multi-user installation, this will be on the high side (yes, there are still places that host actual users and not just their network services).
- How would you manage /tmp space while the system is up? Delete all files > certain age? Leave area alone until it reaches a %age of max?
Look into the tmpwatch command, I think you'll find it suits this part of your question(s) nicely. The command simply deletes any files past a certain age in hours. Depending on how fast it fills up, you could do 30 days, 45 days, 90 days, etc.
- Should any procedural items be placed into effect to govern this area?
I would recommend the following:
- All files are transitory, and are not guaranteed to survive a reboot.
- Stale files past %age will be removed nightly at midnight local time via a cron job that runs the tmpwatch command.
The rest is a matter of your specific needs.
Since Windows 2000, the whoami command has been part of the standard command line (thanks to pk for clearing that up in comments!).
You can do this: Open a command prompt and type "set" then hit enter. This shows active environment variables. Current logged on username is stored in the USERNAME env variable and your domain is stored in the USERDOMAIN variable.
To piggy-back off the other answers, from a cmd line:
echo %USERDOMAIN%\%USERNAME%
will get you the complete logged on user in domain\username format.
You can do the same thing with Powershell with this:
write-host $env:userdomain\$env:username
Best Answer
zfs
When I first read the announcement, I immediately thought of ZFS, as it has had, for years, many of the features touted as groundbreaking by ReFS.
Don't get me wrong, though - Windows badly needs a new filesystem, and this seems to be going in the right direction.
No, not really. On the surface, they share a similar feature set, but they are drastically different architecturally. ReFS is based on NTFS, wheras ZFS (as far as I can tell) was designed from the ground up, with no obvious filesystem ancestors.