Re: Strategy for /tmp and /home Partitioning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mike,


That is (almost) the situation I'm in, now. I've got /boot, /swap,
and /. (Not counting removable medium devices.)

]# fdisk -l

Disk /dev/hda: 40.0 GB, 40020664320 bytes
16 heads, 63 sectors/track, 77545 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1        8625     4346968+   b  W95 FAT32
/dev/hda2   *        8626       60915    26354160    7  HPFS/NTFS
/dev/hda3           60916       61118      102312   83  Linux
/dev/hda4           61119       77545     8279208    f  W95 Ext'd (LBA)
/dev/hda5           61119       76505     7755016+  83  Linux
/dev/hda6           76506       77545      524128+  82  Linux swap

/dev/hda1 and /dev/hda2 are Windows XP, /dev/hda3 is /boot,
hda5 is /, and /dev/hda6 is /swap.

Ah, you'd have a lot more space if you got rid of that windows partition! :)

I'm considering repartitioning and using a file for swap, rather
than a separate partition. That would make the system somewhat
more vulnerable to fs corruption, but I've read where file access
is just as fast, and a file is easier to resize than a partition.

I'd go with the file too in your case, especially when you've got a couple of partitions unusable since they're for Windows.

Partly, this is an exercise in exploring what can be done.

These sorts of things are the best teachers.

My question really revolved around making /tmp into a soft link
to /home/tmp on another disc. I was concerned with possible
race conditions during boot. I've gotten good feedback on using
a loopback mount rather than a soft link (which now that I have
a better understanding of what a loopback mount is, makes sense)
and some assurance that there would be no boot issues.

I'm sure that would work, I have no personal experience with that arrangement.

How *do* you have your system set up?

Well it's a bit different than what you've got, but it looks like this:

Filesystem            Size  Used Avail Use% Mounted on
/dev/rd/c0d0p2         12G  5.0G  6.0G  46% /
/dev/rd/c0d0p1         99M   24M   75M  25% /boot
/dev/rd/c0d1p1         48G   23G   25G  48% /home
/dev/rd/c0d0p5        9.2G  2.5G  6.7G  28% /usr/local
/dev/rd/c0d2p1        291G  197G   95G  68% /shares
/dev/rd/c0d0p6         12G  157M   12G   2% /stuff
none                  2.0G     0  2.0G   0% /dev/shm

It's on a hardware RAID, so c0d0 is the first "disk" (actually a RAID-1 mirror of 2 disks) c0d1 is a 4 disk RAID-5, and c0d2 is a 10 disk RAID-5.

User data lives in /home and /shares, and I put anything I run that's not normal/stock Fedora stuff in /usr/local. That way if it blows up, it either (a) destroys/fills up /usr/local or (b) if I need to recover/reinstall I can reload the OS leaving all my custom stuff intact. The latter reason is also a compelling argument for a separate /home.

Incidentally some Unix flavors, particularly MP-RAS from NCR used the concept of more than one /usr partition for version migration and fallback- you could load a new version of the OS into a new slice (partition) and boot between the new and old to test and either migrate to or roll back from if testing goes badly. Kind of wish Fedora did that...

I thought the way Solaris uses /usr/local is rather nice,
actually.

Me too, I kind of emulate that a bit this way.

Hope that helps a bit

-Mike


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux