Well, that will teach me to post to sun-managers without giving enough local
site information. I discovered two things: 1) very few people actually
know very much about the technical issues involved, as they are esoteric
and occasionally counter-intutive; 2) this is as divisive an issue here as
it is with our user community.
What we finally settled on is:
Main Disk
sd0a / 10 MB
sd0b swap 2.5 * Physical Memory Size
swap /tmp allocated from swap as needed
sd0f /var 20 MB
sd0g /usr 100 MB
sd0h /usr/export/home rest of disk
Of course, we're a bit unusual an environment - the machines I'm managing
average 1.3 GB of disk, we're not running diskless anything, and our
user community generates several hundred megabyte temporary files routinely.
Common arguments:
a) Separate partitions to simplify backups.
Normally a valid consideration, we're running NetWorker so this isn't
an issue.
b) Having separate partitions wastes space, don't do it.
c) Having shrinkwrap partiions makes upgrades and disk recovery much easier.
Yup. One of my primary motivating factors. This may not seem
like such a hardship ("Gee, the OS will grow, so we'll have to
repartition the disk anyway"), but people tend to reload systems
much more often than they realize (disk crashes, machine swaps,
hardware upgrades, ...), so I'd like to make it as easy as possible
to do a shrinkwrapped hardware or software upgrade of any given tool
or piece of the OS.
d) Go diskless (or at least dataless).
Our user community won't stand for it. Putting tools onto tool servers
and automounting them was only accepted because the cross-mounting
was killing people. They want to make sure that every single station
has copies of *everything* - man pages, sundiag, you name it. Except,
of course that none of them want anything installed that they don't
personally use. Argh!
e) Why are you letting your user community mess with machines you maintain?
Because we have to.
f) Try to isolate what comes off the distribution tape from what the local
community changes.
I concur. This is one of the primary motivating factors for the
scheme we settled on. This is beneficial when we do os updates,
machine recovery, and cuts down the amount of detective work we
do on each client trying to determine what state their machine
is in when they need help.
RichardT
>>> tmp:1
Date: Thu, 5 Mar 92 08:19:14 EST
From: lees@cps.msu.edu
Return-path: lees@cps.msu.edu
To: richardt@apple.com
Subject: Partitioning arguments
Sender: sun-managers-relay@eecs.nwu.edu
From: RichardT <richardt@apple.com>
Date: Thu, 05 Mar 92 00:53:44 -0800
Later this week I'm going to have the dubious pleasure of trying to
explain to some of my more obstinate user community why they can't
have their entire disk as one partition. I'm probably also going to
get to explain to them why it is less than wise to have their disk
divided into only root and usr (and swap of course). So I'm busily
collecting arguments for partitioning strategy, and wanted to find
out what other folk are doing to keep their large installations
manageable. How have you chosen to partition your diskful client
machines, and why?
On servers, we do try for the one-disk, one-filesystem approach as much
as possible, because it makes it much easier to swap a disk when we
have a failure. In fact, we've lately begun poor-man's disk mirroring
for critical user filesystems by doing a dump/restore disk-to-disk each
day.
On client machines, we have root, swap and /usr. Some clients have
second disks for special purposes (such as disk-to-disk incremental
backups of server filesystems).
As much as possible, we forbid doing anything to a client to make it
unique. When we install a new version of the OS on a hundred or so
workstations, we do a disk-to-disk clone and run a script to setup
each workstation.
---------- O
John Lees, Pattern Recognition & Image Processing Laboratory OoO
Systems Analyst & Lab Manager, Computer Science Department /O
A714 Wells Hall, MSU, East Lansing, Michigan, 48824-1027 | Peace be
(517) 353-4577, lees@cps.msu.edu, lees@msuegr.bitnet (|) with you!
M i c h i g a n S t a t e U n i v e r s i t y _|_
>>> tmp:2
Date: Thu, 5 Mar 92 07:12:30 CST
From: bill@ihpds1.att.com
Return-path: bill@ihpds1.att.com
To: richardt@apple.com
Subject: Re: Partitioning arguments
I've read your message twice - why do they care
whether it's one partition or not? Is there some
obvious gain I don't know about?
Confused,
Bill Duncan
P.S. Try to keep your client disks as uniform as possible.
>>> tmp:3
Date: Thu, 5 Mar 1992 07:32:34 -0600 (CST)
From: "Anthony A. Datri" <datri@concave.convex.com>
Return-path: datri@lovecraft.convex.com
To: RichardT <richardt@apple.com>
Subject: Re: Partitioning arguments
> I'm probably also going to get to explain to
>them why it is less than wise to have their disk divided into only root and
>usr (and swap of course).
Depending on the size of the disk, it may very well be wise to do so.
======================================================8--<
>>> tmp:4
Date: Thu, 5 Mar 92 14:37:42 +0100
From: Arie Bikker <aribi@geo.vu.nl>
Return-path: @bronto.geo.vu.nl:aribi@geo.vu.nl
To: richardt@apple.com
Subject: Re: Partitioning arguments
Actually we have diskfull clients because diskless couldn't be delivered, so i'
m not a profound believer in disk for the millions.
Here's our setup. We are aiming at centralisation of data for ease of administr
ation and migration.
Workstations have root and mini /usr and swap ofcorse. the rest of the disk is
put
in /local. /local is automatically kept clean by removal of files that haven't
been
accessed for over a week. All clients use an NFS mounted /usr from an executabl
e server
(128 Mb ram so hardly any disk activity on this server). The home directories a
re kept
on another set of servers and mounted through the automounter.
advantages:
- single location of executables mounted readonly aleviates the task of keeping
in pace
with the updates of all those packages.
- /local contains only stuff that i wouldn't want to know about. It isn't backe
d up which is also easier for me ;) For the user it has the advantage of more (
albeit temporary) space with high bandwidth. Because they know of the autodelet
ion scheme they
indeed use it only for temporary stuff (during the day).
- having home directories centralized enables me to relocate a user from a crow
ded partition to a more spacier environment, or to do some primitive server loa
d balancing. The automounter will take care of it so that the user won't notice
it.
disadvantages:
- vulnerability! If the Execserver is down so is everybody (doesn't happen that
often though, uptimes are typically above 100 days).
I 've looked at possibilities of tfs, mounting a local partition over a network
ed
partition, and having regular updates in the background. The tfs wasn't stable
enough
to put it into production (daemons dying and the like).
in short our guidelines:
- what everyone has in common should be shared
- local disks are faster so they sould be used for the files that are accessed
most.
i hope this will give you ideas on how to cope with your crowd ;)
greetings,
Arie Bikker
___=======-----
------------------------------------
-- Drs. Arie Bikker --
-- Instituut voor Aardwetenschappen --
-- Vrije Universiteit --
-- Amsterdam Netherlands --
-- aribi@geo.vu.nl --
------------------------------------
>>> tmp:5
Date: Thu, 5 Mar 92 08:32:34 EST
From: don@mars.dgrc.doc.ca (Donald McLachlan)
Return-path: don@mars.dgrc.doc.ca
To: richardt@apple.com
Subject: Re: Partitioning arguments
I use the following configuration on my NIS datales clients.
/dev/sd0a / 16M (more than enough room)
/dev/sd0b (swap) 128M (2x maxphysmem, never needs to grow)
/dev/sd0c (full disk, ~not used)
/dev/sd0d (not used)
/dev/sd0e /tmp 16M (keeps volatile stuff off /)
/dev/sd0f /var 16M (keeps volatile stuff off /)
/dev/sd0g /local_disk whatever is leftover
/dev/sd0h (not used)
I then mount these partitions from the file server.
mars:/export/exec/sun4.sunos.4.1.1
362758 116340 210142 36% /usr (ro)
mars:/export/exec/kvm/sun4c.sunos.4.1.1
49033 16425 27704 37% /usr/kvm (ro)
mars:/export/share/sunos.4.1.1
362758 116340 210142 36% /usr/share (ro)
mars:/usr/games 79838 3182 68672 4% /usr/games (rw)
mars:/usr/local 137023 98068 25252 80% /usr/local (rw)
mars:/var/spool/mail 14983 3719 9765 28% /var/spool/mail (rw)
mars:/home 751442 357021 319276 53% /home (rw)
The main idea for simple management is to have all systems have the same
partitions in the same place (local vs remote, and / on sd0a ...).
All user accounts are on the server for easy backup.
The only strange thing I have done is I export/mount /home, not /home/mars
as Suns default is. The reason is fsck on the server will put lost files in
/home/lost+found. If all you export is /home/mars, users cannot recover their
own lost files without rlogin to the server. Many of them don't know
much about Unix so I try to make life simple for them.
PS, the smaller a patition is the faster the throughput is (less seeking).
Hope some of this is useful, Don
>>> tmp:6
Date: Thu, 05 Mar 92 08:39:56 -0500
From: fed!m1rcd00@uunet.UU.NET
Return-path: fed!m1rcd00@uunet.UU.NET
To: RichardT <uunet!apple.com!richardt@uunet.UU.NET>
CC: cohoes!rcd@uunet.UU.NET
Subject: Re: Partitioning arguments
> Later this week I'm going to have the dubious pleasure of trying to explain
> to some of my more obstinate user community why they can't have their entire
> disk as one partition. I'm probably also going to get to explain to
> them why it is less than wise to have their disk divided into only root and
> usr (and swap of course). So I'm busily collecting arguments for
> partitioning strategy, and wanted to find out what other folk are doing
> to keep their large installations manageable. How have you chosen to
> partition your diskful client machines, and why?
>
> RichardT
> Network Archeologist
We have about 140 machines, variously workstations, servers, and
in between. Our latest and greatest standard configuration works
out like this:
For a server (SPARCstation 2, internal 207 MB, external 1.2MB,
plus any data drives on a second SCSI chain):
On the internal 207MB drive:
/ (root): 14MB
swap: 94MB
/usr: 74MB
/var: 14MB
On the external 1.2GB drive:
/export: 83MB
some more swap
/tmp: 140MB
/sparc1: 195MB
/sparc2: 195MB
/sparc3: 195MB
/sparc4: 102MB
Root is, of course, just root. We make it big so that it can hold a
fair number of kernals.
swap, of course, has to be a seperate partition.
For /usr, we take all the stuff off the distribution CD that we *ever*
need, and build a common /usr. We put in symbolic links all over /usr,
but we try to build it such that we almost never change it, except
maybe to put in more links for a new application. Certainly it never
grows in size beyond 100K or so per year. New OS releases have the
greates effect on this partition.
/var holds spool and logging areas. We also have a lot of symbolic
links out of /etc into here and use it for stuff that varies from
machine to machine.
/export holds share & lib stuff, as well as the man pages and anything
locally installed that is architecture specific, such as top.
/tmp is /tmp
/sparc[1-4] hold all our applications software, and are made to be
identical accross all machines with rdist. In addition, /sparc1 is the
home for anything (such as amd or plp) that the system needs at boot time
but is locally installed; it is checked & mounted on a single-user boot
just like root & /usr. /sparc1 holds /usr/local/{bin,etc,lib,man,...},
as well as the X distribution. The /sparc filesystems can be mounted
on and used by *any* SPARC machine... Sun4, Sun4c, Solbourne,
whatever.
On a workstation, depending on how much disk is avialable and what the
user is going to do with it, the first thing we drop is /sparc[2-3],
then /sparc1, then /export, then /usr. A rock-bottom minimum
installation would be root, swap, & /tmp, with /var included in root.
With dirt-cheap 200MB drives, though, we almost always have at least a
local /usr and a seperate /var.
The nice thing about this is that all the systems are the same, except
for the host name in /etc/rc.boot and stuff like that. If one of those
200 MB or 1.2GB system disks conks out, we can steel one from a machine
that isn't being used that day, or we can just keep one all set up and
on hand, allthough this is tough what with daily rdists and stuff. It
really cuts down on the time to get a user back up and running again.
All the above stuff is managed by the systems staff, and the users
really have no choice in the matter. Those disks "belong" to the
systems staff, and the users can't put anything there except in /tmp
and /usr/tmp, and they know that if /tmp is lost, it's lost. If they
need data space on a machine, they get another disk all to themselves,
and they get to decide however they please how to carve that space up.
One big partition or seven little ones are both fine to us. We do
"negotiate" with them if they want, say, a 1.2GB partition, however,
purely from a practical standpoint: In terms of the amount of time it
takes to back this stuff up and the price of, say a tape write error
80% through a backup, and in limiting the impact of a corrupted
filesystem. In extreme cases, such as the user that needs five 1.2 GB
disks each just one big partition, we'll give him a tape drive and a
box of tapes, and wash our hands of the whole affair. "Here, you do
it." :-)
I'd say that you should focus on what *you* need to support the
machines that you are responsible for. Form a contract with the users
for a certain level of support. Tell them that *you need* a seperate
root, swap, /usr & /tmp in order to support that machine. Don't argue
on this point: it shouldn't be open to consideration. This is your
judgement of what you need in order to do your job. You need root and
/usr to never change so that you don't have to back it up every night,
and so that you don't need seperate backups for every machine. You need
swap seperate because the machine won't work otherwise. You need /tmp
seperate so that you can just newfs the stupid thing if it's broken.
Tell them that they can have it any other way they want, but then they
can back it up and they can fix it if it breaks. You just don't have
the time for that kind of thing.
I've been consistently impressed with how well our users respond to this
approach. They understand where the lines are, and where the
responsibilities are. They respond well to someone who says what they
need to do their job, since they're in the same boat. And don't forget
to maintain a seperate focus on what *they* need. They need disk space
in order to do their job. So find a way to give them disk space, and
give them control over that space. If you back it up for them, then you
should have some say in how it's organized. But if they are willing to
be completely responsible for it, then they should be able to do
whatever they want. Everything has a price.
Good luck,
Bob Drzyzgula
Federal Reserve Board
rcd@fed.frb.gov
>>> tmp:7
Date: Thu, 05 Mar 92 08:57:02 -0600
From: Matt Crawford <matt@oddjob.uchicago.edu>
Return-path: matt@oddjob.uchicago.edu
To: RichardT <richardt@apple.com>
Subject: Re: Partitioning arguments
I used to slice up the user space many ways, and put 1/N of the users
in each partition. During the last system upgrade, having installed
many more systems in the meantime, I decided that "one big pile was
better than N little piles" and I smooshed them all together again.
That's for the main server. Our disked clients tend to have as few
partitions as practical. A separate one for /var or /var/spool if
they need it, and otherwise all on one /home/machinename. We'd
stripe multiple disks together if SunOS allowed it. (We do that on
the bigger SGI machines.)
________________________________________________________
Matt Crawford Astronomy & Astrophysics U of Chicago
>>> tmp:8
Date: Thu, 05 Mar 92 10:03:46 -0500
From: David Rubin <drubin@forte.poly.edu>
Return-path: drubin@forte.poly.edu
To: RichardT <richardt@apple.com>
Subject: Re: Partitioning arguments
>
>Later this week I'm going to have the dubious pleasure of trying to explain
>to some of my more obstinate user community why they can't have their entire
>disk as one partition. I'm probably also going to get to explain to
>them why it is less than wise to have their disk divided into only root and
>usr (and swap of course). So I'm busily collecting arguments for
>partitioning strategy, and wanted to find out what other folk are doing
>to keep their large installations manageable. How have you chosen to
>partition your diskful client machines, and why?
We use one partition for our workstations with ~200MB disk, because we
always ran into problems where the root partition filled up and there was
plenty of space left on /usr. I have never seen any ill-effects from using
one single partition. I am very interested to hear why this might not be
advisable, and about other partitioning strategies people use.
-- Dave>>> tmp:9
Date: Thu, 5 Mar 92 07:08:31 PST From: scheller@asdi.saic.com (Mark Scheller x6519) Return-path: scheller@asdi.saic.com To: richardt@apple.com Subject: Re: Partitioning arguments
First of all, I'm in the same boat. I, too, have users which cannot understand why many partitions which fill up is better than one. I am using the following rationale:
1) Backups are easier. True, since 4.0 (I think) `dump' is able to take and backup directories instead of complete filesystems, however it is still easier to work with dumping entire partitions on different dates than different filesystems.
2) Growth is better managed. When one partition fills up you know where to look for growth. When that partition is a whole 1 GB disk, it is VERY difficult to figure out what grew and who to blame.
A little history on what I did: we have just changed from one machine with three 1 GB drives, each with partitions as large as possible (and not my doing :-) ) to a machine I'm responsible to configure. So I split up the software product area into 4 pieces: one for source, one for objects, one for executables, and the last for data files. The plan was that object files and data files need not be backed up very often, executables not very often either; and as an added bonus it is easier to make tapes of just executables come delivery time, and source needs to be backed up all the time; every night. Also, when the source area gets filled - and I sized it quite a bit larger than the source should (ever) be - then I know people are keeping on-line backups of their source and wasting valuable disk space.
Please send me your findings so I can present better arguments to my `know it all' users.
Thanx,
mS (scheller@asdi.saic.com) Sysadmin/whipping post ============================================================================== Science Applications International Corporation (SAIC) (619)546-6519 (Voice) 10260 Campus Point Dr. M/S-C3, San Diego, CA 92121 (619)546-6174 (FAX) | scheller@asdi.SAIC.COM | "Remember folks. Traffic lights timed for 35 mph ...{backbone}!asdi.SAIC.COM | are also timed for 70 mph." -- Jim Samuels !scheller | ------------------------------------------------------------------------------
>>> tmp:10
Date: Thu, 5 Mar 92 10:40:31 EST From: "Susan Thielen" <thielen@irus.rri.uwo.ca> Return-path: thielen@irus.rri.uwo.ca To: richardt@apple.com CC: thielen@irus.rri.uwo.ca Subject: Re: Partitioning arguments
Yes, we have some disks that have one partition on them.. It was done before my time... I was never really sure on the reasons why this is not such a good idea.. But I have always assumed it was. The reasons I think it is bad are
1. Possibility of running out of inodes 2. Ability to recover other partitions if serious errors occur 3. Making partitions means that if one gets full, everyone on the disk won't suffer... All my users and mail are on one partition.. so when some mindless wonder tar's a tape into their directory, or my silly program dumps an enormous core, everybody suffers. 4. The ability to backup sections of the disk, making recovery of stuff faster when things get lost.
Now these are not really technical sounding reasons, other than the inode question... but I do wonder what would happen if one ran out of inodes and how many are there to begin with. I need more reasons as well to tell the users around here to really convince them this practice is not really a good one.. They think its more cosy to have every user on the same partition... or rather more indicative of a group spirit or something like that... sigh.. I'd like to slice em up via advisors etc.. but... it can be so hard to get them to do those things!!! So.. if you get a bunch more reasons as to why the partitioning is a good idea.. could ya please let me know??
Thanks a bunch
sue %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Susan KJ Thielen Application Programmer, System/Network Manager Advanced Imaging Lab Robarts Research Institute Phone: (519) 663-3833 PO Box 5015, 100 Perth Drive Fax: (519) 663-3789 London, ON N6A 5K8 E-mail: thielen@irus.rri.uwo.ca %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>> tmp:11
Date: Thu, 05 Mar 92 09:14:38 -0500 From: Benson I. Margulies <benson@odi.com> Return-path: benson@odi.com <benson@odi.com> To: RichardT <richardt@apple.com> Subject: Re: Partitioning arguments
Later this week I'm going to have the dubious pleasure of trying to explain to some of my more obstinate user community why they can't have their entir e disk as one partition. I'm probably also going to get to explain to them why it is less than wise to have their disk divided into only root and usr (and swap of course). So I'm busily collecting arguments for partitioning strategy, and wanted to find out what other folk are doing to keep their large installations manageable. How have you chosen to partition your diskful client machines, and why?
RichardT Network Archeologist
I agree with the users. I try to give the users the biggest possible partition, since otherwise there is always disk space wasted.
It would help if you'd give an idea of the amount of disk in question.
>>> tmp:12
Date: Thu, 5 Mar 92 11:16:06 EST From: Hanh Vu - xt 2801 <hanh@sol.cse.fau.edu> Return-path: hanh@sol.cse.fau.edu To: richardt@apple.com (RichardT) Subject: Re: Partitioning arguments
> Later this week I'm going to have the dubious pleasure of trying to explain > to some of my more obstinate user community why they can't have their entire > disk as one partition. I'm probably also going to get to explain to > them why it is less than wise to have their disk divided into only root and > usr (and swap of course). So I'm busily collecting arguments for > partitioning strategy, and wanted to find out what other folk are doing > to keep their large installations manageable. How have you chosen to > partition your diskful client machines, and why? > > RichardT > Network Archeologist >
Hello RichardT,
Disk partitioning will allow you to mount only a specific part of your file system onto client machines. You get a lot more control this way, and your file systems will be much more organized. Why mount the whole thing when only part of it is required? For example, all our mail comes to one server with a large disk. On this disk, /var is a separate partition. To make the mail boxes available to all users on client workstations, we just mount /var/spool/mail on these machines. No duplicate mailboxes and the users can get their mail on any host.
Proper disk partitioning can be very nice (if not crucial) especially if your setup is distributed. If you have a large disk and want to put all the users into one big partition, you can mount this partition on all your client machines. This will allow any user to log into any machine and access his/her directory without any duplication (with proper password access, of course). This is how Yellow Pages works. If you plan to run YP, you should seriously consider partitioning your servers to more than just / and /usr.
Be careful not to get too zealous on partitioning, however. You can easily make a partition smaller, but you can't resize it larger without having to reformat the whole disk. You should plan also on future growth of any partition containing working directories (/tmp and /var/tmp) since these will grow as the number of users on your system grows.
Hope this helps.
-hanh
--------------------------------------------------------------------------- | Hanh Vu | | | Dept. of Computer Science and Engineering | Internet: hanh@cse.fau.edu | | Florida Atlantic University | Office: (407) 367-2801 | | Boca Raton, FL 33431 USA | Fax: (407) 367-2800 | ---------------------------------------------------------------------------
>>> tmp:13
Date: Thu, 5 Mar 92 09:21:30 MST From: era@niwot.scd.ucar.EDU (Ed Arnold) Return-path: era@niwot.scd.ucar.EDU To: richardt@apple.com Subject: Re: Partitioning arguments
}Later this week I'm going to have the dubious pleasure of trying to explain }to some of my more obstinate user community why they can't have their entire }disk as one partition. I'm probably also going to get to explain to }them why it is less than wise to have their disk divided into only root and }usr (and swap of course). So I'm busily collecting arguments for }partitioning strategy, and wanted to find out what other folk are doing }to keep their large installations manageable. How have you chosen to }partition your diskful client machines, and why?
When we receive an IPC with 4.1.1 pre-loaded on its disk, we immediately re-partition the disk so only local swap and /tmp are on it, and make it a client of our Auspex. It's just too much hassle to be supporting close to a hundred clients with OS software (and esp. local mods) on every one of them ... ---------- Ed Arnold * NCAR * POB 3000, Boulder, CO 80307-3000 * 303-497-1253(voice) 303-497-1137(fax) * era@ncar.ucar.edu [128.117.64.4] * era@ncario.BITNET
>>> tmp:14
Date: Thu, 5 Mar 92 8:24:52 PST From: ralph@swmerc.rain.com (Ralph Merwin) Return-path: ralph@swmerc.rain.com To: richardt@apple.com (RichardT) Subject: Re: Partitioning arguments
> > > Later this week I'm going to have the dubious pleasure of trying to explain > to some of my more obstinate user community why they can't have their entire > disk as one partition. I'm probably also going to get to explain to > them why it is less than wise to have their disk divided into only root and > usr (and swap of course). So I'm busily collecting arguments for > partitioning strategy, and wanted to find out what other folk are doing > to keep their large installations manageable. How have you chosen to > partition your diskful client machines, and why?
When you get this list assembled, please post it. I have both a medium-sized drive split into a couple of partitions, and a large drive setup as one partition. The split drive is a definite pain, which seems counter to your position...
Ralph
>>> tmp:15
Date: Thu, 5 Mar 92 08:34:07 PST From: aldrich@sunrise.stanford.edu (Jeff Aldrich) Return-path: aldrich@sunrise.stanford.edu To: richardt@apple.com Subject: Re: Partitioning arguments
>Later this week I'm going to have the dubious pleasure of trying to explain >to some of my more obstinate user community why they can't have their entire >disk as one partition. I'm probably also going to get to explain to them >why it is less than wise to have their disk divided into only root and usr >(and swap of course). So I'm busily collecting arguments for partitioning >strategy, and wanted to find out what other folk are doingto keep their >large installations manageable. How have you chosen to partition your >diskful client machines, and why?
Taken in order:
1. Although a system could run with a single partition (nothing magic about /usr being off by itself, and swap could be set up with mkfile), it would be pretty difficult to install it and boot it up. ;-)
2. Assuming a single-disk system, you definitely don't need any more than the standard three chunks. What is gained by divvying up the disk in more sections? File organization can be dealt with under /usr with symlinks to /<mystuff> if needed, as long as *everything* that didn't come off the CD is easily filtered from the rest, such as with /usr/local or whatever. Backups are simpler (you can either take advantage of high-capacity dump devices, or limit dumps to the subset of the partition that you really care about dumping), and you don't have to be concerned about future usage requirements changing the partition setup.
For some time now, I've set up all the machines I take care of with as few partitions as possible: /, swap and /usr on first or single disks, and /usrN with maybe another chunk of swap, if needed, for all others. It's made my life a bit simpler, and has brought no problems.
BUT. I always at least double the default size of /, so there is adequate /tmp (which may not be an issue in your environment), and I make sure that /usr/tmp isi't symlinked back to / via /var/tmp, so print and mail spools don't get caught short and wedge the system.
Anyway, it's what works here on a great variety of machines. Your mileage, as always, may vary. Good luck!
................................................ Jeff Aldrich <aldrich@sunrise.Stanford.EDU> R&D Engineer Center for Design Research Stanford University
>>> tmp:16
Date: Thu, 5 Mar 92 10:03:25 CST From: skb@cypress.com (Scott Butler) Return-path: cypress.com!skb@cypress.com To: richardt%apple.com@cypress.cypress.com Subject: Re: Partitioning arguments
I am not aware of any significant advantage to multiple partitions. I would like to know why people have and continue to do this.
As for arguments against, the main one for us is that at times we need to support very large files, and do not want to waste the space associated with multiple partitions.
Please include me in your summary. ------------------------------------------------------------------------------- Scott Butler Telephone : (612) 851-5036 Cypress Semiconductor Inc. Fax : (612) 851-5199 2401 E. 86th Street E-Mail : skb@cypress.com Bloomington,MN 55425, USA -------------------------------------------------------------------------------
>>> tmp:17
Date: Thu, 5 Mar 92 11:38:28 -0500 From: pete@cs.UMD.EDU (Pete Cottrell) Return-path: pete@cs.UMD.EDU To: richardt@apple.com Subject: Re: Partitioning arguments
Long ago, we chose a configuration for the U of Md. Computer Science department and UM Institute for Advanced Computer Studies (UMIACS) machines; from what we can tell, not too many other people do things this way. On the client local disk, we have root, swap and the user files. /usr is on a server. People point out that we are losing the ability to have heavily- used parts of /usr cached on the local disk; this is true. We are also incurring the headache of having every local disk different from any other one because of the users' data, so we must back up each disk; also, upgrading or repairing a machine after a disk problem is more tedious, because we cannot just drop the canonical client disk image onto the machine - we have to worry about the user data. These are indeed shortcomings. But we still like doing things this way. All user writes are to the local disk, so we've pretty much eliminated the NFS-write slowdown (except on the small clusters of machines where certain groups have their filesystems cross mounted. Even then, most of these users are writing to their local disk). We also avoid the problem of space allocation and disk quotas. The users of a machine have their own disk space, and when they start filling it up, they work among themselves to free up some room, or else they buy another local disk (1GB local disks are becoming more popular (and cheap)). Yes, backups are a pain, but there are lots of products out there that can help with this problem - we have developed our own network dump tool internally, which people may end up hearing about in the near future if they happen to read Usenix proceedings. And our server dumps aren't quite as bad as they might be if we had tons of user files on them. This isn't a common configuration, but it has worked for us for a long time (7 years). Hope this helps.
>>> tmp:18
Date: Thu, 05 Mar 1992 17:38:10 +0100 From: Frank Kuiper <frankk@cwi.nl> Return-path: frankk@cwi.nl To: RichardT <richardt@apple.com> Subject: Re: Partitioning arguments
> RichardT <richardt@apple.com> writes > on Thu, 05 Mar 1992 00:53:44 -0800: > > Later this week I'm going to have the dubious pleasure of trying to explai n > to some of my more obstinate user community why they can't have their enti r > disk as one partition. I'm probably also going to get to explain to > them why it is less than wise to have their disk divided into only root an d > usr (and swap of course). So I'm busily collecting arguments for > partitioning strategy, and wanted to find out what other folk are doing > to keep their large installations manageable. How have you chosen to > partition your diskful client machines, and why?
basically user has nothing, absolutely nothing to do with system partitions. So all user partions are seperate. Gives you to possibillity to mount /usr, /usr/local and others as read-only. Makes the service more relyable, less points of faillure. You use different partitions to establish fixed borders of disk usage. Again to make the entire system more reliable. Third it's also for convenience sake for the administrator. If you users don't by this, explain to them it gives you more time to help them with serious things. Forth, less down time for trouble machine, when you can easily copy material (if necessary using raw dd) from other machine, therefore better service.
We have diskfull Sparcs, with local root and swap. Rest of the disk (some 50Mb) is for user space. Private to the main user of the machine. Makes it possible in most cases to continue some work, even while the server is down.
If this isn't enough, tell them to take care of the entire machine themself. They'll soon come back to you.
Good luck.
Frank Kuiper . ___ Internet: frankk@cwi.nl _][__| | X.400: PN=frankk; O=cwi; PRMD=surf; ADMD=400net; C=nl <_______|-1 Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch. O-O-O
>>> tmp:19
Date: Thu, 5 Mar 92 11:42:12 EST From: George A. Planansky <gplan@aer.com> Return-path: gplan@aer.com To: richardt@apple.com Subject: Partitioning arguments
It is hard to resist answering this question.
1. Filesystems like / and /usr should be isolated from /tmp, /users_tmp_workspace, /home/users, /usr/local/{bin,lib,doc,whatever}, /var/{log,spool, /ftp, /news, and the like,
a. keep sunos delivered stuff that doesn't change separate from other stuff, and stuff that changes, so you can do upgrades, and other things, in a sane, ordered way.
b. keep local site config stuff separate, and local host specific stuff separate, for sanity and convenience, as above.
c. if some filesystems fill up, the machine will hang etc. So keep user home areas, and user workspace areas, separate from root, system spool, /tmp (compilation workspace), filesystems. You don't want to bring the system down because three people copied tapes to /tmp at the same time, or a lot of news came in over the holiday.
d. keep highly variable stuff (workspace, homespaces, spools) separate from never changing or slowly changing stuff, to facilitate backups and restores.
e. keep partitions smaller than the capacity of your backup and tar tapes, for convenience and sanity. Easy to do if you use exabytes.
f. because it's your responsibility and that's how you choose to do it. (The people in the grocery store don't tell the farmer how to divide his fields, rotate his crops, do they?)
2. if concerns like those above are not an issue, then certainly the larger and fewer the number of partitions, the more flexibility you have in using a filesystem.
George Planansky Atmospheric & Environmental Research Cambridge, MA 02139 gplanansky@aer.com (617) 547-6207
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% " Well, it ain't baseball, but it's a livin." -- Eddie Gaedel, ca. 1952, Ringling Brothers circus %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>> tmp:20
Date: Thu, 5 Mar 92 12:11:58 -0500 From: kevinmac@ll.mit.edu (Kevin McElearney) Return-path: kevinmac@ll.mit.edu <kevinmac@ll.mit.edu> To: richardt@apple.com Subject: Re: Partitioning arguments
> Later this week I'm going to have the dubious pleasure of trying to explain > to some of my more obstinate user community why they can't have their entire > disk as one partition. I'm probably also going to get to explain to
Too bad. I think for data disks and home disks it is a great thing. I hate multiple partitions.
> them why it is less than wise to have their disk divided into only root and > usr (and swap of course). So I'm busily collecting arguments for
This is fine too. You get optimal use of disk space. Keep root around 16M, move tmp and spool into usr and root will stay a fixed size. usr can grow to the full size of the disk. A few changes need to be made but I do this all the time and it works fine. Nothing I hate more than having one partition 100% full while another is wasting 100M.
> partitioning strategy, and wanted to find out what other folk are doing > to keep their large installations manageable. How have you chosen to > partition your diskful client machines, and why?
On the diskful client machines I put swap and data. All usr and root is on a server. This enables me to make quick and easy mods to all clients without using the big security hole (.rhost files) I also link /tmp to the local disk data area. Works GREAT!
My vote is with your "obstinate user community" Kevin McElearney ----------------------------------------------------------------------------- MIT Lincoln Laboratory Phone: (617) 981-3556 244 Wood Street Lexington, MA 02173-9108 EMail: kevinmac@ll.mit.edu
>>> tmp:21
Date: Thu, 5 Mar 92 11:49:01 EST From: etnibsd!vsh@uunet.UU.NET (Steve Harris) Return-path: etnibsd!vsh@uunet.UU.NET To: uunet!apple.com!richardt@uunet.UU.NET (RichardT) Subject: Re: Partitioning arguments
> > > Later this week I'm going to have the dubious pleasure of trying to explain > to some of my more obstinate user community why they can't have their entire > disk as one partition. I'm probably also going to get to explain to > them why it is less than wise to have their disk divided into only root and > usr (and swap of course). So I'm busily collecting arguments for > partitioning strategy, and wanted to find out what other folk are doing > to keep their large installations manageable. How have you chosen to > partition your diskful client machines, and why? > > RichardT > Network Archeologist >
The first commandment of disk partitions: Thou shalt not use the root or usr partitions for anything other than system files!
Because root and usr must fsck cleanly at reboot, it is essential to keep them small.
We choose to have /tmp be a symlink to a directory on a large partition. This means the root partition must have a stub version of this directory (which will be hidden when the large partition is mounted) to run in single-user mode. E.g.:
/tmp -> home/tmp.root
(in single user mode, there really does exist a directory /home/tmp.root on the root partition).
Also, we do not remove files from /tmp at reboot, rather, removal is performed by a nightly cron task (actually, by a shell script run by cron: /usr/local/etc/donightly)
find /tmp/. -type f -mtime +2 -exec rm '{}' \;
Other candidates for separate partitions:
/home or /users for users home directories
(the following may not apply to diskful clients)
/log for syslog and other log files, so that runaway logging does not overflow other partitions
/aps for 3rd party applications (don't clutter up /usr) (to be exported read-only??)
-- Steve Harris - Eaton Corp. - Beverly, MA - uunet!etnibsd!vsh
>>> tmp:22
Date: Thu, 5 Mar 92 10:29:24 MST From: "Hilarie Orman" <ho@cs.arizona.edu> Return-path: ho@cs.arizona.edu To: richardt@apple.com Subject: Re: Partitioning arguments
Hello again.
My experience is that it is far better to have fewer partitions than many. For things that are nearly completely static, like root, it might as well be a separate partition, it makes upgrades a little easier. But I would like to see /usr merged into the rest of the disk. The standard configuration here at the University is to have a large /usr partition with /usr/var embedded in it. That's OK, but it is wasteful, and I can understand people objecting. In general, the fewer partitions the better.
>>> tmp:23
Date: Thu, 5 Mar 92 12:29:13 EST From: "John Paul O'Brien" <john@solar.nova.edu> Return-path: john@solar.nova.edu To: richardt@apple.com (RichardT) Subject: Re: Partitioning arguments
> From: RichardT <richardt@apple.com> > Subject: Partitioning arguments > To: sun-managers@eecs.nwu.edu > Date: Thu, 05 Mar 92 00:53:44 -0800 > Message-Id: <2071.699785624@apple.com> > > > Later this week I'm going to have the dubious pleasure of trying to explain > to some of my more obstinate user community why they can't have their entire > disk as one partition. I'm probably also going to get to explain to > them why it is less than wise to have their disk divided into only root and > usr (and swap of course). So I'm busily collecting arguments for > partitioning strategy, and wanted to find out what other folk are doing > to keep their large installations manageable. How have you chosen to > partition your diskful client machines, and why? > > RichardT > Network Archeologist >
Richard,
I think I missed something here. Is having an entire disk be one partition a "bad thing"? I understand why you can't do it on a boot disk but what are the problems doing this with a disk that will just be used for user data?
John
-- John Paul O'Brien, Manager of Technical Services Nova University Academic Computing and Strategic Technology Center 3301 College Avenue, Ft. Lauderdale, Fl. 33314 Phone: (305) 475-7633 UUCP: ...{gatech!uflorida,ucf-cs}!novavax!john Internet: john@solar.nova.edu
>>> tmp:24
Date: Thu, 5 Mar 92 11:32:01 CST From: kwthomas@nsslsun.nssl.uoknor.edu (Kevin W. Thomas) Return-path: kwthomas@nsslsun.nssl.uoknor.edu To: richardt@apple.com Subject: Re: Partitioning arguments
>Later this week I'm going to have the dubious pleasure of trying to explain >to some of my more obstinate user community why they can't have their entire >disk as one partition.
The explanation is simple. Tell them things won't work with just one partition .
>I'm probably also going to get to explain to >them why it is less than wise to have their disk divided into only root and >usr (and swap of course).
It depends on your configuration. All of my IPCs have root, swap, and usr on their disk. I also have a small /tmp filesystem on each local disk too. All of the users files are located on our server system. Ditto for scratch space. Everything except /var/spool/mail is automounted.
>So I'm busily collecting arguments for >partitioning strategy, and wanted to find out what other folk are doing >to keep their large installations manageable. How have you chosen to >partition your diskful client machines, and why?
Our servers filesystems look like:
Filesystem kbytes used avail capacity Mounted on /dev/xy0a 22620 12323 8035 61% / /dev/xy0g 240254 150052 78190 66% /usr /dev/xd1e 143517 77365 58977 57% /usr/local /dev/xy0h 536580 337856 171895 66% /src /dev/xd1d 238943 178393 36656 83% /export /dev/xd1f 1553928 1020810 455422 69% /scratch /dev/sd0a 19469 7081 10442 40% /backup /dev/sd0d 94286 20050 64808 24% /var /dev/sd0e 712653 360402 280986 56% /nssl/nsslsun /dev/sd0f 873642 471449 358511 57% /scratch_faa /dev/sd0g 235136 133405 78218 63% /usr2 swap 179184 12272 166912 7% /tmp
Xy0 is a Sun 892mb drive. Xd1 and xy0 are both Seagate 2.5gb drives.
Client disks look like:
Filesystem kbytes used avail capacity Mounted on /dev/sd0a 12463 6519 4698 58% / /dev/sd0g 114695 88278 20683 81% /usr /dev/sd0h 7699 473 6457 7% /tmp
Each IPC disk (207 mb) is a clone of the others, with about a half dozen or so files different.
I might mention that some of the /usr stuff, such as /usr/share/man is automounted, instead of being stored on the IPC disk. I had to do that to allo w our users to have 64mb of swap space on the IPCs.
Kevin W. Thomas National Severe Storms Laboratory Norman, Oklahoma
>>> tmp:25
Date: Thu, 5 Mar 92 10:11:10 PST From: fabrice@sj.ate.slb.com (Fabrice Le Metayer) Return-path: fabrice@sj.ate.slb.com To: richardt@apple.com Subject: Re: Partitioning arguments
> I'm probably also going to get to explain to > them why it is less than wise to have their disk divided into only root and > usr (and swap of course).
I am not sure why you say that. This is the way all my diskfull clients are partitioned...
Regards,
-- Fabrice
>>> tmp:26
Date: Thu, 5 Mar 92 09:57:08 PST From: markg@shasta.nextwave.com (Mark Glasser) Return-path: markg@shasta.nextwave.com <markg@shasta.nextwave.com> To: richardt@apple.com Subject: Partitioning arguments
I hope you'll post a summary. I'm also interested to hear what everyone has to say on this subject.
Mark Glasser ------------------------------------------------------------------------ markg@nextwave.com Nextwave Design Automation 2339 Charleston Rd #A Mountain View, CA 94043 (voice) 415.691.0332 (fax) 415.691.0334 ------------------------------------------------------------------------
>>> tmp:27
Date: Thu, 5 Mar 92 10:55:51 PST From: jaf@inference.com (Jose A. Fernandez) Return-path: jaf@inference.com Organization: Inference Corporation To: richardt@apple.com Subject: Partitioning arguments
Later this week I'm going to have the dubious pleasure of trying to explain to some of my more obstinate user community why they can't have their entire disk as one partition. I'm probably also going to get to explain to them why it is less than wise to have their disk divided into only root and usr (and swap of course). So I'm busily collecting arguments for partitioning strategy, and wanted to find out what other folk are doing to keep their large installations manageable. How have you chosen to partition your diskful client machines, and why?
Here are my arguments, for what they're worth.
PERFORMANCE:
You get better performance by moving your work area to its own partition. The reason is that the file system code doesn't have to rummage through a lot of unnecessary information to serve you.
For example, supposing you have your disk partition into / and /usr, and that you create and use the directory /usr/MyProject. When you create a file, the file system code has to deal with all the information about /usr in order to accomplish your file creation. When you extend your file (i.e., make it bigger), the file system has to contend with the free list of the ENTIRE /usr partition. Count the sea of inodes in the /usr partition and consider that your /usr/MyProject files are droplets in that sea.
If you were to put /usr/MyProject in its own partition, the number of inodes is *much* lower (unless MyProject is immense) and you get an efficiency gain in the file system code.
RELIABILITY:
The dump/restore utilities provides a reasonable, simple back package. Using the example above, your /usr/MyProject files are immersed amongst all the files in /usr, and dump has to scan all the files in /usr. By putting /usr/MyProject in its own partition, dump works *much* faster.
Suppose the system disk(s) completely crap out and you must reinstall the operating system. By keeping /usr/MyProject in its own partition, you can restore your operating system backups (you *did* make OS backups, didn't you? :-), then your project backups, and you are back on the air in a few hours (modulo the mass of your backups and the speed of your media).
I hope this helps. Good luck.
>>> tmp:28
Date: Thu, 5 Mar 1992 11:56:25 PST From: mike@fionn.lbl.gov (Michael Helm) Return-path: mike@fionn.lbl.gov To: RichardT <richardt@apple.com> Subject: Re: Partitioning arguments
I usually have a small root & a reduced /usr partition as well as swap on diskful machines. I usually mount /usr from some robust server tho.
>>> tmp:29
Date: Thu, 05 Mar 92 11:21:31 -0800 From: sid@ingres.com Return-path: rtech!ingres.com!sid@Sun.COM To: RichardT <richardt@apple.com> Subject: Re: Partitioning arguments
depends on the disk space of course - on those with small amounts, standard 16 mb for root, 32mb for swap and the rest for usr with 100mb disks. For 200mb disks, probably the rest for usr also. For larger, then 200mb for ./usr, may another 8mb for /var and then the rest for /home.
Good luck, -- Sid Shapiro -- Ingres, an ASK Company sid@ingres.com (415)748-3470
>>> tmp:30
Date: Thu, 5 Mar 92 15:08:52 EST From: rrb@math.wayne.edu (Robert Bruner) Return-path: rrb@math.wayne.edu To: richardt@apple.com Subject: Re: Partitioning arguments
Just off the top of my head, here are a few arguments for partitioning (which have implications for strategy). It's been a while since I thought about these things so they may be obsolete and are certainly incomplete. I'd be interested to see what you come up with if you type up a summary.
1) Locality of reference. By collecting files of a type into a partition, accesses to those files can often be quite a bit faster because they aren't scattered all over the disk.
2) Ease of backup. Some types of files change rarely (/usr) and others change a lot (/home). It makes sense to backup /home a lot more frequently and completely, as a result. Also, restoring a lost file to /home is faster if the dump file is smaller.
3) Flexibility in mounting and exporting filesystems. I guess NFS may vitiate this argument since you can mount subdirectories. I suspect there is still some advantage in this regard however.
4) Ability to boot faster and without the entire disk being in good shape. If a minimal system is in a partition just big enough for it, you can get the system up far enough to work on it more easily when something goes wrong. (Yeah but how often does this happen? On the other hand you sure appreciate having planned ahead when it does.)
Argument against: It is a real pain moving things because you have outgrown a partition.
Point I always thought should matter but which no one responds to:
Shouldn't you think about where in the disk things are located and attempt to put the most frequently referenced stuff in the middle and the least frequently referenced stuff at the edges?
>>> tmp:31
Date: Fri, 6 Mar 1992 09:10:16 +1300 From: Ray Brownrigg <Ray.Brownrigg@isor.vuw.ac.nz> Return-path: Ray.Brownrigg@isor.vuw.ac.nz To: richardt@apple.com Subject: Re: Partitioning arguments
We have our disks partitioned in terms of backup strategy and functionality.
I.e. we have partitions for / /usr /usr/local and /home. /home get incrementally backed up every day and every week (at a higher level), /usr/local gets incrementally backed up every week, and everything gets a full backup every month.
In addition I would consider a separate partition for news, pc files (served to PC-NFS) etc. These (as with /usr/local) make system upgrades or file system corruption easier to handle.
One disadvantage of having many partitions is when you are chronically short of disk space. YOu will find yourself swapping things around a lot, to 'borrow' space from a partition which has some.
Ray Brownrigg ray@isor.vuw.ac.nz
>>> tmp:32
Date: Thu, 5 Mar 92 15:10:02 -0500 From: roger@SST.LL.MIT.EDU (Roger L. Hale) Return-path: roger@sst.ll.mit.edu To: richardt@apple.com Subject: Re: Partitioning arguments
I can well imagine how dubious the pleasure...
Why? What's wrong with a whole disk as one partition? or with just root, swap and /usr? We do it all the time. Is this some odd policy of apple.com? I'd hate to have it getting in the way of _my_ large installation!
Roger Hale <roger@sst.ll.mit.edu> Shard of Flint
>>> tmp:33
Date: Thu, 5 Mar 92 13:41:06 MST From: liz@isis.cgd.ucar.EDU (Liz Coolbaugh) Return-path: liz@isis.cgd.ucar.EDU Organization: Climate and Global Dynamics Division/NCAR, Boulder, CO To: richardt@apple.com CC: Subject: Re: Partitioning arguments
In addition to system partitions, we currently set up each user with a /home/user and /data/user partitions. The reasons are for backup purposes. Since the system areas are cloned from a central copy, we do not back them up. The /home/user partition is backed up nightly while the /data/user partition is for temporary data and is never backed up. We currently back up about 5GB of data per night with this setup. If we had to back up all systems everytime, we would have something close to 20GB to back up instead.
Of course, I wouldn't mention to your users that under 4.1 and 4.1.1, you can now back up just part of a partition instead of the entire partition :-). I don't know how well full restores would work under this scenario ...
Another reason is ease of moving users from one workstation to another. If they get a new workstation, we move their directories over. The file systems are crossmounted via the automounter network wide, so no changes to their code are necessary when the directories move from one machine to another.
Hope this helps ... I'll be interested in the other answers :-).
Liz
>>> tmp:34
Date: Thu, 5 Mar 92 14:38:28 EST From: heiser@tdw220.ed.ray.com (Bill Heiser) Return-path: rayssd!tdw220.ed.ray.com!heiser@uunet.UU.NET To: richardt@apple.com (RichardT) Subject: Re: Partitioning arguments
> RichardT wrote: > > Later this week I'm going to have the dubious pleasure of trying to explain > to some of my more obstinate user community why they can't have their entire > disk as one partition. I'm probably also going to get to explain to > them why it is less than wise to have their disk divided into only root and > usr (and swap of course). So I'm busily collecting arguments for > partitioning strategy, and wanted to find out what other folk are doing > to keep their large installations manageable. How have you chosen to > partition your diskful client machines, and why? >
I'd be interested in seeing a summary of this, as I tend to disagree with the things you've outlined above.
Thanks, bill
-- Bill Heiser Work: heiser@sud509.ed.ray.com Home: bill@unixland.natick.ma.us Public Access Accounts for E-MAIL, USENET, and UNIX 508-655-3848
>>> tmp:35
Date: Thu, 5 Mar 92 13:56:13 PST From: derik@osi.com (Derik Jarne) Return-path: derik@osi.com To: sacto!apple.com!richardt@sacto.West.Sun.COM Subject: Re: Partitioning arguments
I ask why not have a disk be one big partition....I haven't run into any serious draw backs...We have two 1.2 Gigabytes disks as /home and /home2....When you are developing applications its nice not to break up source code over many disks or partitions....HAVE you ever just lost a partition on a disk...Not usually if anything the whole disk dies...
Let me know what technical reasons support not doing it this way... (Besides the fact that disk access may be slower)....
Derik@sparc2.osi.com Objective Systems Integrators
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:37 CDT