Linux - NewbieThis 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!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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??
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.
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.
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.
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.
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.
For some restricted cmds (ie ones not in your $PATH), you can still run them if you know where they live eg
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.