How many filesystems (OSR506a Disk partitions)
Bob Meyers
loses storage management flexibilty. Below is a stock Redhat 8.0, Dell
server that RedHat was installed at the factory. The command 'df -m' outputs
in Megabytes.
# df -m
Filesystem Mbytes Used Available Use% Mount
/dev/sda8 1011 161 799 17% /
/dev/sda3 99 11 83 11% /boot
/dev/sda6 5698 1430 3979 27% /home
/dev/sda9 1011 33 927 4% /tmp
/dev/sda5 17094 5362 10864 34% /usr
/dev/sda7 5698 110 5299 3% /var
To me this is too many filesystems. I would favor the 2 or 3 max filesystems
for this disk: a /, /u and maybe a /u2 at most. Is my preference a bad
practice?
Stuart J. Browne
Depends on application.
I agree that the default partitioning schems of red hat are too broken up,
and don't represent a real world need.
We use a 3 partition scheme:
/boot
/
/home
As our data lives under the user dir's.
other's would say that more caution is required, like making a /var so that
your log files/spool directories don't fill up your root space.
some would say the same sort of thing for /usr.
In practice however, /usr should be pretty much static. /boot on a SCSI
system is un-necessary.
Do what you are comfortable with.
bkx
Brian K. White
there is a logical and legitimate reason for each of those to be
seperate filesystems, but I think it's largely a
philisophical/religeous issue these days.
on the above system, runaway syslog or other logs, web/ftp server,
print jobs, mail spool etc... none of those can fill up the disk and
crash the whole system, only the service in question and a
comparatively few other things will stop when say var fills up. users
are less likely to fill up the whole disk as long as they don't know
there are other directories they can write to besides their home dirs.
/boot never needs to be very big, and in the case of linux it should
be small and fall entirely within the first 1024 cylinders of the disk
so that lilo will work. except now both lilo and grub can access the
whole disk I think as long as you know how to set it up and as long as
your bios is new enough. many bios's still can't handle that though
without pretty ugly workarounds in both hardware & software. many
people like / to be just big enough to hold the core OS. stuff that
generally doesn't grow over time. makes it easier in some disaster
recovery situations if the OS and the applications & data are
seperate. That leaves /usr for the main body of user-space stuff
applications & data that aren't already in var or a home directory.
If you had an extremely large system, perhaps it would be easier to do
backups because you could backup the non-changing and the expendable
stuff less frequently on their own tape (/, /boot, /usr & /tmp you
just back up the dir not the contents) then the volotile data you back
up every day and maybe that is more likely to fit all on one tape or
one tape per filesystem (/var, /home)
Personally, although I see the rationale(s), and can imagine many
situations where it would be better/easier if they were seperate.. .in
practice those situations have just not occured aften enough to matter
to me. I've had to recover from tapes and recover as much data as
possible from drives that could no longer boot or run on their own
etc... I've had cases where the print or mail spool filled up the
drive and stopped everyone from being able to work... It never would
have made much difference so far.
I vasillate between preffering one single filesystem (not counting
/boot or it's sco equivalent /stand) and two / and /u /u being for
the main applications & data. It is often handy to have at least one
OS/APPS split.
Aside from all of the above, I also like to keep a seperate filesystem
in the form of a whole seperate dedicated disk for large masses of a
particular form of data. like a big database, or in my case, a tree
structure of scanned documents. (png, tiff, or gif files) This makes
it easier to migrate this data to larger and larger disks without
having to touch the rest of the system.
I would say that the many seperate fs's are classically more
technically "right" but I never voluntarily set up a new disk that
way.
My usage pattern though is a lot of 10-50 user boxes and a few >100
user boxes. Perhaps on >100 user boxes it becomes more important,
assuming proportionally greater data & disk sizes.
John DuBois
options appropriate for that data - tmp, nolog, ronly, etc.
John
--
John DuBois spc...@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/
Bill Vermillion
<oregon...@yahoo.com> wrote:
>In earlier message I said some Linux flavors have so many files
>systems one loses storage management flexibilty.
How can fewer file systems give you more flexibilty. More give you
more flexibility but along with more demands on thinking of where
things logically belong.
>Below is a stock Redhat 8.0, Dell server that RedHat was
>installed at the factory. The command 'df -m' outputs in
>Megabytes.
># df -m
>
>Filesystem Mbytes Used Available Use% Mount
>/dev/sda8 1011 161 799 17% /
>/dev/sda3 99 11 83 11% /boot
>/dev/sda6 5698 1430 3979 27% /home
>/dev/sda9 1011 33 927 4% /tmp
>/dev/sda5 17094 5362 10864 34% /usr
>/dev/sda7 5698 110 5299 3% /var
>To me this is too many filesystems. I would favor the 2 or 3 max
>filesystems for this disk: a /, /u and maybe a /u2 at most. Is
>my preference a bad practice?
There are good precedences for having separate filesystems
for /tmp and /var. On SCO the booting file system is a different
structure to be bootable, so that makes 3.
This way you never crash a system with /tmp going astray or getting
too full.
On some Unix systems the home is mounted under /usr - and that
scheme makes sense to me.
Mounting /usr separately is a good move >>IF<< nothing in /usr
needs to be operational in single user mode. That's one reason
that the SCO Xenix and Unix systems never made /usr separate as
many things in /usr were needed at boot.
Think of this as progress. Things that made a lot of sense
when a big disk was 20MB require different approaches now.
In some systems in the past I've tried to look at useage
and put some things on different drives so that head contention was
minimized. Again - that was in the days of 60ms drive access too.
Bill
--
Bill Vermillion - bv @ wjv . com
Dan Skinner
> In article <b3b383$1kh0ia$1...@ID-105888.news.dfncis.de>, Bob Meyers
> <oregon...@yahoo.com> wrote:
> Think of this as progress. Things that made a lot of sense
> when a big disk was 20MB require different approaches now.
>
> In some systems in the past I've tried to look at useage
> and put some things on different drives so that head contention was
> minimized. Again - that was in the days of 60ms drive access too.
>
> Bill
Bill et al;
Not to offend, but:
One of the signs of progress is an internet with hundreds of news
groups each with hundreds of posters we've never met nor have we
reviewed their CV (except of course what they post.)
One of them says no file systems over 2 gig, or never login as root
(unless you must of course and then su.)
Three days of news group postings and its cannon law.
I'm sure in some specific cases many of these are good practice, but a
little more common sense and a little less post a question and jump on
an answer from a 12 year old just might produce better results.
Food for thought?
Regards…Dan.
Bill Vermillion
Dan Skinner <JDanS...@JDanSkinner.com> wrote:
>b...@wjv.comREMOVE (Bill Vermillion) wrote in message news:<HAtFr...@wjv.com>...
>> In article <b3b383$1kh0ia$1...@ID-105888.news.dfncis.de>, Bob Meyers
>> <oregon...@yahoo.com> wrote:
><snip>
>> Think of this as progress. Things that made a lot of sense
>> when a big disk was 20MB require different approaches now.
>>
>> In some systems in the past I've tried to look at useage
>> and put some things on different drives so that head contention was
>> minimized. Again - that was in the days of 60ms drive access too.
>>
>> Bill
>Bill et al;
>Not to offend, but:
>One of the signs of progress is an internet with hundreds of news
>groups each with hundreds of posters we've never met nor have we
>reviewed their CV (except of course what they post.)
Hundreds of newsgroups with hundreds of posters? When I started
carrying and distributing a full news feed there were 3000 groups -
about 1500 in the big six and 1500 alt group, and a full feed was
about 20-30MB day. We did all that on 1200bps modems.
The goal to shoot for on those systems was three drives. One to
take the incoming files, one to spool the news too, and a third for
the log & history files. This prevented spindle contention and
improved things drastically. This is also called load balancing
and on busy systems still can be important.
>One of them says no file systems over 2 gig, or never login as root
>(unless you must of course and then su.)
The 2GB file system limit was pretty much hardware/software
imposed at least on systems based on iNTEL processors. A 32 bit
signed int - which was all you had to indicated the size of a file
said and at that time file system gave the 2,147,483,647 size
limit. [I still keep the binary/oct/hex calculator I got in about
1997 by the keyboard - I didn't dredge that up from memory].
>Three days of news group postings and its cannon law.
The NGs of today are not nearly as accurate as they were in the
past. A lot of urban legend passes by and no one seems to
be able to look up real references anymore.
There are good technical papers on file systems available for those
who want to know.
>I'm sure in some specific cases many of these are good practice, but a
>little more common sense and a little less post a question and jump on
>an answer from a 12 year old just might produce better results.
Well I've been using Unix systems since 1983 so that fact alone
make me older than a 12 year old :-)
If you want to understand the whys and wherefores books on OS
design an implemtation are a good place to start - you will then
see the rational behind many of the recommendations.
Bach's book on the SysV2 system is a good starting point. The BSD
books by Lefler, McKusik,et al give additional understanding.
Then looking at older systems and what was done to overcome limits
is quite interesting.
I have no idea of how many computer books I've accumlated over the
years - but there are hundreds. One of my friends who has an MS in
CompSci was using the same books in class that I had.
>Food for thought?
Books followed by thought are so much more rewarding. Food for
thought - if you have too much - might give you a fat head. It
does that to my stomach :-).
And as to the CV you'll see no CS on mine as there weren't any
offered where I went to school. A great many engineering courses
before I switched majors from an EE track. [I saw no joy in
designing hydroelecrtic/power systems - I liked things on a smaller
scale ]
As to the 3 days of NG postings you'll see many here who have
been posting for years and by going back and reading these you can
tell that they do know what they are doing. Never trust anything
year read on the 'net if it doesn't make sense if you don't know
the posters background.
I think I first ran across JPR on Compuserve about 1984. Bela I
notice in the Dr.Dobbs group in 1986. There are a lot of us here
who have been posting and helping for a long time. If you count
the time before I had access to the 'net and was part of a
tech mailing group back in 1980 [there were 3000 of us on H&R
Block's MicroNet at that time - they changed the name to Compuserve
later] that's 23 years of helping others - and you'll find others
on this particular group who have been doing it even long, CV's not
withstanding.
And I've seen many with credentials that still have a problem
determing a stope from an equus assinus.
Stuart J. Browne
> I think I first ran across JPR on Compuserve about 1984. Bela I
> notice in the Dr.Dobbs group in 1986. There are a lot of us here
> who have been posting and helping for a long time. If you count
> the time before I had access to the 'net and was part of a
> tech mailing group back in 1980 [there were 3000 of us on H&R
> Block's MicroNet at that time - they changed the name to Compuserve
> later] that's 23 years of helping others - and you'll find others
> on this particular group who have been doing it even long, CV's not
> withstanding.
*blink*
Ok, now I feel truely humbled *nod*.
3 weeks and I'll be 26. *whee!*.
I'd like to just give a broad thanks to those who have been helping here, for
no other reward than the thanks and respect of their peers.
The experience, and knowledge that you offer up to us is qutie astounding,
and helps us poor 'younguns' to no end.
Thank you.
Bkx
--
Yes! I am a pixie!
Ralf Muschall
> Using separate filesystems for certain data also means that you can use mount
> options appropriate for that data - tmp, nolog, ronly, etc.
Additionally, one can use different filesystem types for different
data. E.g. at home, I have a /var/spool/news as reiserfs (unsafe in
the case of a crash, but fast and efficient for small but unimportant
files).
In a world where 500Mb intermediary postscript files are a rather
common case, having a separate /var is a good idea anyway (if the
printer runs out of paper, a few dozens of such files might try to
stick in the system).
Ralf
--
GS d->? s:++>+++ a+ C++++ UL+++ UH++ P++ L++ E+++ W- N++ o-- K- w--- !O M- V-
PS+>++ PE Y+>++ PGP+ !t !5 !X !R !tv b+++ DI+++ D? G+ e++++ h+ r? y?
Dan Skinner
My apologies for offence taken though not intended.
Bill, your post contained reason and analysis not always encountered
in these posts and I guess inspired me (should that be set me off?)
The real trigger was a thread on another group, which will remain
nameless, although it is in support of a major software development
platform.
Summary:
1. Obvious gym shoe OP makes a request for help with a specific data
entry problem.
2. Gets about 6 responses that missed the point.
3. Gets 2 very similar responses that solve the problem with one line
of
code.
4. Gets 1 response with more than a screen of code (I didn't count the
lines) that might solve the problem (I didn't read the code.)
5. OP posts thanks for the input with special thanks to the 2 simple
ones
and says he/she is going to try suggestion 4.
I had to take it out on someone.
You're right we wouldn't be here if not for the thoughtful, hopeful
questions and the reasoned, seasoned answers. I just have to get used
to filtering the chaff.
Regards…Dan.
Bill Vermillion
>> > I think I first ran across JPR on Compuserve about 1984. Bela I
>> > notice in the Dr.Dobbs group in 1986. There are a lot of us here
>> > who have been posting and helping for a long time. If you count
>> > the time before I had access to the 'net and was part of a
>> > tech mailing group back in 1980 [there were 3000 of us on H&R
>> > Block's MicroNet at that time - they changed the name to Compuserve
>> > later] that's 23 years of helping others - and you'll find others
>> > on this particular group who have been doing it even long, CV's not
>> > withstanding.
>> *blink*
>> Ok, now I feel truely humbled *nod*.
>> 3 weeks and I'll be 26. *whee!*.
>> I'd like to just give a broad thanks to those who have been
>> helping here, for no other reward than the thanks and respect
>> of their peers.
>> The experience, and knowledge that you offer up to us is qutie
>> astounding, and helps us poor 'younguns' to no end.
Many of the people that helped me are long gone, but without the
help when I got started I'd have not made it this far or become
addicted to these wee small beasts. That made for my last career
change from recording engineer to computer <something> in 1983.
And sometimes the first days are the hardest. I remember trying
to start up my first Xenix system - before there were hardware
clocks - so it started off with the time it was last shut down.
It wanted me to input the time and no matter what I did I could NOT
get the format right. I did not know at the time it would let me
in even if I didn't set the time - so after about 10-15 minutes I
got frustrated and turned it off and came back the next day.
I got it working then and it started me of in this direction.
Years ago when there were such things as local computer groups -
one guy was an ex-navy commander kept promoting the 'pay it
forward philsophy [long before any movie of that name].
Since you can't pay back those who taught you, you were obligate to
pass that knowledge on. Eveyone in that group then still follows
that philsophy.
>My apologies for offence taken though not intended.
I didn't see anything offensive.
>Bill, your post contained reason and analysis not always encountered
>in these posts and I guess inspired me (should that be set me off?)
Well it try to be reasonable at most times :-)
>The real trigger was a thread on another group, which will remain
>nameless, although it is in support of a major software development
>platform.
[some groups aren't worth reading because of the poor value of
technical information. Much of my information comes from only two
NGs and many mail lists - where the clueless can be removed if they
get too bad]
>Summary:
>1. Obvious gym shoe OP makes a request for help with a specific data
> entry problem.
>2. Gets about 6 responses that missed the point.
>3. Gets 2 very similar responses that solve the problem with one line
>of
> code.
>4. Gets 1 response with more than a screen of code (I didn't count the
> lines) that might solve the problem (I didn't read the code.)
>5. OP posts thanks for the input with special thanks to the 2 simple
>ones
> and says he/she is going to try suggestion 4.
>I had to take it out on someone.
I didn't think you were taking it out but just making a commentary
to which I responded.
>You're right we wouldn't be here if not for the thoughtful, hopeful
>questions and the reasoned, seasoned answers. I just have to get used
>to filtering the chaff.
After you read the groups for awhile you get a feel for them and
you know whose posts you always read along with those who never get
anything right - and may wind up in a kill file.
The hardest part in anything technical is to educate yourself
enough so that when a post comes up that doesn't look quite right
you mentally question the answer. If you always attempt to
undestand what/why you are doing something you'll amost never
fall into disasters because someone posted some wrong-information.
I've once had a rather nasty and heated exchange with a techincal
editor of a fairly popular magazine targeted toward Unix system as
he was giving wrong information. His only excuse was that it was
information passed along from readers. Sounds like some of
today's NGs doesn't it. And I've seen other popular columnists
pass on mis-information when they had enough name recognition they
could have gone direct to the manufacturers and gotten the exact
information.
I will say that learning in an 8-bit world as I did and getting the
fundmamentals down was far easier than trying to understand it all
in the current environment.
Recently I put in a 120GB drive in a web-server I maintain. Just
for grin I computed the cost of floppies to store the same amount
of data on my first system. It came out to about 130,000+ boxes
of floppies what cost [not listed] for about $6,500,000. Early
computer was easier to understand but far less affordable.
Stephen M. Dunn
In article <3e5996de$0$37690$8ee...@newsreader.tycho.net> spc...@deeptht.armory.com (John DuBois) writes:
$Using separate filesystems for certain data also means that you can use mount
$options appropriate for that data - tmp, nolog, ronly, etc.
I have some temp and spool directories on a filesystem that's mounted
with -otmp (OSR5.0.5, pretty well all patches applied, and the
filesystem is HTFS). I've tried mounting it without -otmp. Subjectively,
I don't notice any difference in performance. I haven't tried any
objective benchmarks. And the disk access patterns sound the same
whether I specify -otmp or not; for example, a process which creates
lots of small files (for example, sucknews) generates a whole pile of
disk activity, including heavy seeking, each time a file is created,
followed by what I'm assuming is data being committed according to the
settings of BDFLUSHR and NAUTOUP.
The man page says -otmp filesystems "are updated less
frequently" - what sorts of updates are done less frequently? From
what I can see, it doesn't appear to be a significant difference.
--
Stephen M. Dunn <ste...@stevedunn.ca>
>>>----------------> http://www.stevedunn.ca/ <----------------<<<
------------------------------------------------------------------
Say hi to my cat -- http://www.stevedunn.ca/photos/toby/
Bob Meyers
"Bill Vermillion" <b...@wjv.comREMOVE> wrote in message
news:HAtFr...@wjv.com...
> In article <b3b383$1kh0ia$1...@ID-105888.news.dfncis.de>, Bob Meyers
> <oregon...@yahoo.com> wrote:
>
> >In earlier message I said some Linux flavors have so many files
> >systems one loses storage management flexibilty.
>
> How can fewer file systems give you more flexibilty. More give you
> more flexibility but along with more demands on thinking of where
> things logically belong.
> >To me this is too many filesystems. I would favor the 2 or 3 max
> >filesystems for this disk: a /, /u and maybe a /u2 at most. Is
> >my preference a bad practice?
>
> There are good precedences for having separate filesystems
> for /tmp and /var. On SCO the booting file system is a different
> structure to be bootable, so that makes 3.
>
> This way you never crash a system with /tmp going astray or getting
> too full.
Are you sure it won't crash anyway? For instance services and apps may start
crashing if they don't have /tmp or lost control of an application temporary
file. A delayed crash maybe.
John DuBois
Stephen M. Dunn <ste...@bokonon.stevedunn.ca> wrote:
> This is really just for the sake of curiosity.
>
>In article <3e5996de$0$37690$8ee...@newsreader.tycho.net> spc...@deeptht.armory.com (John DuBois) writes:
>$Using separate filesystems for certain data also means that you can use mount
>$options appropriate for that data - tmp, nolog, ronly, etc.
>
> I have some temp and spool directories on a filesystem that's mounted
>with -otmp (OSR5.0.5, pretty well all patches applied, and the
>filesystem is HTFS). I've tried mounting it without -otmp. Subjectively,
>I don't notice any difference in performance. I haven't tried any
>objective benchmarks. And the disk access patterns sound the same
>whether I specify -otmp or not; for example, a process which creates
>lots of small files (for example, sucknews) generates a whole pile of
>disk activity, including heavy seeking, each time a file is created,
>followed by what I'm assuming is data being committed according to the
>settings of BDFLUSHR and NAUTOUP.
>
> The man page says -otmp filesystems "are updated less
>frequently" - what sorts of updates are done less frequently? From
>what I can see, it doesn't appear to be a significant difference.
Some of the filesystem metadata that normally is flushed when some measures of
its age exceed a threshold isn't flushed for that reason alone if the
filesystem is mounted with -otmp. Other things, including other measures of
its age, will still cause it to be flushed.
Bill Vermillion
It may or may not. But you never want to fill up root. As long as
it is OK an su should be able to kill off things that have filled
/tmp, but a full / is a pain.
But a crashed app should only be a crashed app and not take down
the system. If it does there is something wrong with the app.
Bob Meyers
"Bill Vermillion" <b...@wjv.comREMOVE> wrote in message
>
> But a crashed app should only be a crashed app and not take down
> the system. If it does there is something wrong with the app.
How's that saying go? Something about perfection is divine and to err is
human...
Bill Vermillion
I don't know when the last time was that I had an app go astray
that took out the system. It's been a long time. But if you have
something that scribbles like mad on your root partition and fills
it you can have some interesting problems.
One problem is that so many programs install themselves in
/usr and /usr needs to be part of the / file system as many program
needed at boot time are on that partition.
Before drives got bigger some people would create another /usr
and when the system went multi-user it just mounted the new
/usr on top of the old /usr.
Making the /u and making sure that all aps install there saves a
lot of grief and will let you run / with under 1GB of space.
That is handy as you can umount and then just backup / before
making major changes - and on a decent system that takes well under
10 minutes.
I like separate filesystems. Far too many don't seem to follow
the 'rules' that first appeared in 'man hier' back in
Version 7. It's been updated over the years for the systems that
still use it and refering to that while it make look complicate
[based on your comments on the RH defaults] it makes good sense
>to me<.
Bill