LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 01-05-2012, 03:09 PM   #16
jorran
Member
 
Registered: Dec 2011
Location: Iowa
Distribution: RHEL 5.X
Posts: 54

Original Poster
Rep: Reputation: Disabled

The only thing that I dont completely understand is the /home and /usr. /usr is the largest share of data on a system so why not partition that out and not /home... unless /usr is under home and is really /home/usr??
 
Old 01-05-2012, 04:36 PM   #17
salasi
Senior Member
 
Registered: Jul 2007
Location: Directly above centre of the earth, UK
Distribution: SuSE, plus some hopping
Posts: 4,064

Rep: Reputation: 894Reputation: 894Reputation: 894Reputation: 894Reputation: 894Reputation: 894Reputation: 894
Quote:
Originally Posted by jorran View Post
Or is it completely up to me?
Nearly; you can decide based on operational requirements which you want as separate partitions. So, if you have a lot of bandwidth being used on one particular area, that can be an argument for using a separate partition. That said, there are certain things that can't work, easily. So, as /etc is needed during start-up, making that a separate partition, which isn't mounted until the system has gone through the start-up procedure is problematic (not impossible, but beyond the current scope, and generally 'too clever by half' for an introductory discussion).

The reason that I mentioned having a separate 'home' partition specifically earlier is that there can be an advantage in doing this; When you install another Linux (either an upgrade to a later version, or a different version), this way there is the potential of keeping your existing data files intact, if they are on a separate partition. This saves a measure of 'backing up to some medium and restoring from the medium' (you'll still want a back-up, though, for obvious reasons).

Note also that 'mount points' don't necessarily have to be at the top level of the hierarchy. So, for example, /home could be included within '/', but you could decide to put /home/data1/user1, /home/data1/user2, /home/data1/user3 on one partition (and probably, in this case, physical disk) and /home/data2/user4, /home/data2/user5, /home/data2/user6 on another. That particular variant would be most useful if you have the data from several users stored on one machine, and the most likely case then would be if this was a fileserver used across the network (eg, via NFS), so it probably wouldn't be relevant to get into too much detail of the options regarding NFS, but you get the general idea.

Quote:
If I have 8TB of data/files being looked though each and every day by thousands of customers...
Now, that puts a different aspect on this discussion, which hadn't really had an easily definable purpose until then. This has the potential to be a lot of bandwidth, and the storage device could spend a lot of its time getting this data.
  • Where is the data? Is it on /home, or somewhere else? If some particular application is using this data, it may have some preference in where this data goes.
  • what kind of data is it? Is it a mass of small files, or, say, a big database (eg, a mysql database or databases)?

There is a suspicion that the data itself could, to advantage, be on a separate partition, but really we'd have to know more to be better positioned to give a good answer, for some particular set of circumstances, rather than just the generic overview of how things work in principle.
 
Old 01-05-2012, 04:51 PM   #18
jorran
Member
 
Registered: Dec 2011
Location: Iowa
Distribution: RHEL 5.X
Posts: 54

Original Poster
Rep: Reputation: Disabled
Does this help at all? I ran df on one of the servers... are these all separate mounts? Partitions?


Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol02
42215948 25259744 14777132 64% /
/dev/mapper/VolGroup00-LogVol00
9903432 2157896 7234356 23% /home
/dev/sda1 101086 31926 63941 34% /boot
tmpfs 8139976 0 8139976 0% /dev/shm
/dev/mapper/binaries--vg-binaries--lv
100791728 3793692 91878036 4% /opt/IBM/WebSphere
/dev/mapper/2009--vg-2009--lv
1023887200 547243844 476643356 54% /data/cm/2009
/dev/mapper/current--vg-current--lv
1138287040 1066372280 71914760 94% /data/cm/current
/dev/mapper/2008--vg-2008--lv
921529600 577315204 344214396 63% /data/cm/2008
/dev/mapper/1996--vg-1996--lv
208379776 188061680 20318096 91% /data/cm/1996
/dev/mapper/1997--vg-1997--lv
387665984 357025500 30640484 93% /data/cm/1997
/dev/mapper/1998--vg-1998--lv
157269536 148656736 8612800 95% /data/cm/1998
/dev/mapper/1999--vg-1999--lv
153581184 149170140 4411044 98% /data/cm/1999
/dev/mapper/2000--vg-2000--lv
255976480 166837136 89139344 66% /data/cm/2000
/dev/mapper/2001--vg-2001--lv
437308752 428693972 8614780 99% /data/cm/2001
/dev/mapper/2002--vg-2002--lv
358372560 323253404 35119156 91% /data/cm/2002
/dev/mapper/2003--vg-2003--lv
1028412944 900583568 127829376 88% /data/cm/2003
/dev/mapper/2004--vg-2004--lv
640774064 399509108 241264956 63% /data/cm/2004
/dev/mapper/2005--vg-2005--lv
563143856 455711028 107432828 81% /data/cm/2005
/dev/mapper/2006--vg-2006--lv
588750096 490992692 97757404 84% /data/cm/2006
/dev/mapper/2007--vg-2007--lv
1177460256 534992080 642468176 46% /data/cm/2007
/dev/mapper/2010--vg-2010--lv
1187311680 1112068652 75243028 94% /data/cm/2010
/dev/mapper/2011--vg-2011--lv
1572691840 265340 1572426500 1% /data/cm/2011


Most of the data is small files but many of them to my knowledge. What other commands would be helpful to run to gain more insight?
 
Old 01-05-2012, 07:00 PM   #19
chrism01
LQ Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.9, Centos 7.3
Posts: 17,411

Rep: Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397
That would be easier to read if you used code tags https://www.linuxquestions.org/quest...do=bbcode#code.
Another useful cmd here is
Code:
fdisk -l
that's a lowercase L switch there BTW ...

Basically df shows the 'logical' layout from the user's pt of view; fdisk shows the physical layout
http://linux.die.net/man/

HTH


PS "many of them to my knowledge" ??? missing a word or two there?
 
Old 01-06-2012, 06:53 AM   #20
salasi
Senior Member
 
Registered: Jul 2007
Location: Directly above centre of the earth, UK
Distribution: SuSE, plus some hopping
Posts: 4,064

Rep: Reputation: 894Reputation: 894Reputation: 894Reputation: 894Reputation: 894Reputation: 894Reputation: 894
Quote:
Originally Posted by jorran View Post
Does this help at all? I ran df on one of the servers... are these all separate mounts? Partitions?


Code:
Filesystem                          1K-blocks       Used      Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol02           42215948        25259744  14777132  64% /
/dev/mapper/VolGroup00-LogVol00           9903432         2157896   7234356   23% /home
/dev/sda1                                 101086          31926     63941     34% /boot
tmpfs                                     8139976         0         8139976   0%  /dev/shm

/dev/mapper/binaries--vg-binaries--lv    100791728        3793692   91878036  4% /opt/IBM/WebSphere
/dev/mapper/2009--vg-2009--lv            1023887200       547243844 476643356 54% /data/cm/2009
/dev/mapper/current--vg-current--lv      1138287040       1066372280 71914760 94% /data/cm/current
/dev/mapper/2008--vg-2008--lv            921529600        577315204 344214396 63% /data/cm/2008
/dev/mapper/1996--vg-1996--lv            208379776        188061680 20318096  91% /data/cm/1996
/dev/mapper/1997--vg-1997--lv            387665984        357025500 30640484  93% /data/cm/1997
/dev/mapper/1998--vg-1998--lv            157269536        148656736 8612800   95% /data/cm/1998
/dev/mapper/1999--vg-1999--lv            153581184        149170140 4411044   98% /data/cm/1999
/dev/mapper/2000--vg-2000--lv            255976480        166837136 89139344  66% /data/cm/2000
/dev/mapper/2001--vg-2001--lv            437308752        428693972 8614780   99% /data/cm/2001
/dev/mapper/2002--vg-2002--lv            358372560        323253404 35119156  91% /data/cm/2002
/dev/mapper/2003--vg-2003--lv            1028412944       900583568 127829376 88% /data/cm/2003
/dev/mapper/2004--vg-2004--lv            640774064        399509108 241264956 63% /data/cm/2004
/dev/mapper/2005--vg-2005--lv            563143856        455711028 107432828 81% /data/cm/2005
/dev/mapper/2006--vg-2006--lv            588750096        490992692 97757404  84% /data/cm/2006
/dev/mapper/2007--vg-2007--lv            1177460256       534992080 642468176 46% /data/cm/2007
/dev/mapper/2010--vg-2010--lv            1187311680       1112068652 75243028 94% /data/cm/2010
/dev/mapper/2011--vg-2011--lv            1572691840       265340    1572426500 1% /data/cm/2011

Most of the data is small files but many of them to my knowledge. What other commands would be helpful to run to gain more insight?
(I've put the data into code tags...no guarantee I've restored the data as it would have been originally, as some of the tabs will have been corrupted, but hopefully you should see the advantage of doing this. Just easier to read, by an order of magnitude, when the columns are 'prettied up' a bit.)

There are now two parts to this answer: this thread, so far, has concerned the 'plain vanilla' method of dealing with the data on disk. All of the '/dev/mapper....vg-....' stuff is something else. These items are Logical Volume Groups, via the Logical Volume Manager, and are rather different.

Anything that says 'dev/sda*' is a conventional partition and has a conventional fixed size, etc. For the LVM '/dev/mapper...' stuff, the size is more flexible. That is, for the Logical Volume Manager stuff, the LVM itself is given a whole heap of disk space, and it hands it out to the various partitions, as required. Given this flexibility, the LVM groups are in less danger of running out of space (provided LVM itself is correctly configured, and has an appropriate amount of space to hand out - it doesn't actually manufacture disk space out of thin air, although it may initially feel like that).

It looks as if someone has already set about structuring this so that the high usage items are on the LVM groups (I suspect that this is now more what you are interested in than what you actually asked originally, but correct me if I am wrong), but you'll have to drill down deeper to find out more.

Note also that the fact that this is an LVM arrangement doesn't say anything about the layers underneath; it could, for example, be a group of disks; they could be 'straightforward' disks, it could be a raid arrangement of multiple disks looking like one big disk. You'll probably have to go beyond my ability to help if you want to get into the nitty-gritty, and it will have stretched way beyond the ambit of the original title of this thread, and probably also the 'newbie' remit, too.
 
Old 01-06-2012, 10:41 AM   #21
jorran
Member
 
Registered: Dec 2011
Location: Iowa
Distribution: RHEL 5.X
Posts: 54

Original Poster
Rep: Reputation: Disabled
do you have to have root access to run fdisk -l? It says command does not exist.
 
Old 01-06-2012, 12:15 PM   #22
Cultist
Member
 
Registered: Feb 2010
Location: Chicago, IL
Distribution: Slackware64 14.2
Posts: 779

Rep: Reputation: 105Reputation: 105
Quote:
Originally Posted by jorran View Post
do you have to have root access to run fdisk -l? It says command does not exist.
Yes, fdisk has to be run in root, but you just have to run a terminal as root. To do this, you just have to type
Code:
su
into a terminal window from your regular user account, and enter the root password.
 
Old 01-06-2012, 12:27 PM   #23
Cedrik
Senior Member
 
Registered: Jul 2004
Distribution: Slackware
Posts: 2,140

Rep: Reputation: 243Reputation: 243Reputation: 243
Or use ' mount ' command without argument to list mounted partitions
(edit)
Sorry, didn't see the mount names from df output

Last edited by Cedrik; 01-06-2012 at 12:28 PM.
 
Old 01-06-2012, 12:35 PM   #24
jorran
Member
 
Registered: Dec 2011
Location: Iowa
Distribution: RHEL 5.X
Posts: 54

Original Poster
Rep: Reputation: Disabled
and that is the problem, I dont have root access or know the password to su access... the company who manages the linux environment will not give me access... they either dont know how lol or are just being cute. They lost their linux guy so I think they are just scared that if I play with the system and something happens they wont know how to fix it.
 
Old 01-09-2012, 12:15 PM   #25
jorran
Member
 
Registered: Dec 2011
Location: Iowa
Distribution: RHEL 5.X
Posts: 54

Original Poster
Rep: Reputation: Disabled
Would there be any benefit in having a /app directory specifically for applications? Or would it be acceptable just to have the applications install where they are 'suppose' to? Like below...
•/bin & /sbin are for vital programs for the OS, sbin being for administrators only ;
•/usr/bin & /usr/sbin are for not vital programs, sbin being for administrators only ;
•/var is for living data for programs. It can be cache data, spool data, temporary data (unless it's in /tmp, which is wiped at every reboot), etc. ;
•/usr/local is for locally installed programs. Typically, it hosts programs that follow the standards but were not packaged for the OS, but rather installed manually by the administrator (using for example ./configure && make && make install) as well as administrator scripts ;
•/opt is for programs that are not packaged and don't follow the standards. You'd just put all the libraries there together with the program. It's often a quick & dirty solution, but it can also be used for programs that are made by yourself and for which you wish to have a specific path. You can make your own path (e.g. /opt/yourcompany) within it, and in this case you are encouraged to register it as part of the standard paths ;
•/etc should not contain programs, but rather configurations.
 
Old 01-09-2012, 07:58 PM   #26
chrism01
LQ Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.9, Centos 7.3
Posts: 17,411

Rep: Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397Reputation: 2397
For some restricted cmds (ie ones not in your $PATH), you can still run them if you know where they live eg
Code:
/sbin/fdisk -l


As for the LVMs, looks like a new LVM for each year's worth of data; not a bad idea in some cases.
It all really depends on what how the App works.
If it's not broken, don't fix it.
If they have a specific issue, let us know what it is.

Re LVMs
http://tldp.org/HOWTO/LVM-HOWTO/

See also http://www.linuxtopia.org/online_boo...ion/index.html
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Copy Folder Hierarchy 1veedo Linux - General 1 07-02-2010 02:00 PM
APT Repository Hierarchy baking-a-77 Linux - Software 0 02-19-2009 04:50 PM
Why are so many dirs used in solaris hierarchy? wrapster Solaris / OpenSolaris 4 06-19-2008 04:13 AM
[SOLVED] Distribution Hierarchy Mustafa^Qasim Linux - Newbie 2 02-24-2007 10:16 PM
#include hierarchy Mistro116@yahoo.com Programming 2 11-27-2005 12:50 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 02:18 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration