Re: Adding a new drive / fstab
On Thu, Jul 10, 2008 at 11:33 AM, V. Alex Brennen <[EMAIL PROTECTED]> wrote: > The reason that many people avoid putting anything under '/' that is not > created by the operating system itself is that if you have any type of > problem mounting the disk space that you plan to use under that > directory, your programs or system can fill the '/' partition ... The same would be true of /mnt/, of course, unless that is its own filesystem separate from the root. And on many (most?) modern Linux distros, the default is for one big partition for everything. If one sets permissions on the underlying mount point such that write access is denied, you could solve that problem without resorting to a separate partition just for mount points. "chattr +i /mnt", for example. Myself, I haven't worried about it much, but I haven't had to deal much with different filesystem storages on the same host. If one filesystem isn't mounting, it will generally be noticed immediately, because all sorts of things won't be working. If I had big storage appliances or lots of cross-mounts, like you described, my story would likely be different. "Experience is what you get by not having it when you need it" and all that. :) I *do* tend to create separate filesystems, but for other reasons. I'm most concerned with a runaway process filling up the filesystem it is *supposed* to be writing to. For example, a malfunctioning process generating tons of log messages can fill up the log partition. (Which can in turn cause all sorts of processes to hang/crash.) So I isolate them for that reason. It also localizes filesystem fragmentation, and allows for more selective use of the "noexec" option to "mount" as a defense against malware. I use LVM rather than simple partitions to make resizing/reallocation easier. For example, on the GNHLUG server, there are LVs for / (root), swap, /usr, /usr/local, /home, /sites, /tmp, /var/, /var/log, and /var/spool. > Linux has become somewhat resistant to these types of problems. I can say from recent experience that a full filesystem can impair a modern Linux system pretty effectively. :-/ Some of the fancier filesystems don't use inodes; I expect they'd be immune from inode exhaustion. But they can still run out of space, of course. > Many default disk partitioning plans, including those of RedHat and many > others, create a very small '/' partition. Red Hat (and derivatives) hasn't done things that way for years. Their default scheme is to create a small /boot/ partition, and then create one big / partition for everything else. The reason for that is *that* various bootloaders, motherboards, BIOSes, etc., have had issues booting from large disks. Ubuntu is the same way, as I recall. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Adding a new drive / fstab
Many people said to just "use what works for you." I agree. There's no deep need to conform to the POSIX HFS standard. Especially, since many of the points in the standard come from negotiation with the makers of flavors of UNIX which are now long dead or dying. If you look at the LSB equivalent of the HFS standard, you can see it is much less verbose and allows much more freedom for the administrator. Regarding creating an additional mount point in the root directory, which was also suggested, there are reasons why you may not want to do that. The reason that many people avoid putting anything under '/' that is not created by the operating system itself is that if you have any type of problem mounting the disk space that you plan to use under that directory, your programs or system can fill the '/' partition (either its available blocks or its available inodes). On some systems, this can cause booting and operational problems with your server bringing some or all of your service down. Linux has become somewhat resistant to these types of problems. It is much more so than the older *NIX Operating Systems. But, on Linux you would still encounter some problems. Depending on how your OS Disk(s) are partitioned, those problems could be very serious. This issue with filling up disk partitions for which parts of your core operating system are depending on being able to write to has been written about extensively. The majority of the content on the web comes from security sites and deals with including /var (and especially /var/log) on a partition that can be filled by an individual who has access to your system with only basic user permissions. For example, having /var on the same disk partition as /home and not having quota restrictions in place. Additional content can be found regarding what will happen to applications if application/service critical directories such as /tmp, /var/tmp, /var/spool/mail, /var/postgres, etc., can easily be filled by even a non-malicious user. Many default disk partitioning plans, including those of RedHat and many others, create a very small '/' partition. So, it can quickly be filled before you even notice that you've had a problem. Some distributions will also not properly separate critical portions of the file system onto independent partitions (such as /var and /home). So, I'd recommend that while you should do what ever works for you, it would also be good to think about what could possibly go wrong. I've run into problems myself before on Gentoo by not creating a separate partition for /afs and then having an AFS boot sequence fail because the local AFS service was having problems. I then, stupidly, had the same problem some time later on a RH system by not creating a separate LV for /mnt and then having a SAN array mount failure during boot. - VAB - V. Alex Brennen [EMAIL PROTECTED] Senior UNIX Systems Administrator MIT Libraries E25-131 x3-9327 http://vab.mit.edu/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Adding a new drive / fstab
On Wed, Jul 09, 2008 at 11:50:46AM -0400, Labitt, Bruce wrote: > In the endless pursuit of upgrading this machine I have added a hard > drive to my computer. I have used fdisk to create a linux partition to > the whole disk. I made the disk use the ext3 file system. > > So now for fstab. What is the philosophy for creating an entry? At > this point I'm not sure what the mount point should be. /home sounds I generally mount additional "disks" for data storage as /data/n/. Simple, clean, easy to understand & maintain. These days, for production servers, my typical partitioning is: /boot / /tmp /var /opt (if I'm going to install much 3rd party software that will use it) /data /home and /usr/local are symlinks into /data, as is /opt if I haven't given it a separate partition. If additional data "disks" are needed, I either use LVM to add space to /data, or mount the additional volumes as /data/1/, /data/2/, etc. Ocassionally (usually for Oracle servers) I will create other application-specific filesystems, but it is getting more and more rare as app developers gain clue. -- [EMAIL PROTECTED] OpenPGP KeyID 0x57C3430B Holder of Past Knowledge CS, O- "Would you rather me stick it in your chicken?" Richard Jerrell ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Adding a new drive / fstab
On Wed, Jul 9, 2008 at 11:50 AM, Labitt, Bruce <[EMAIL PROTECTED]> wrote: > ... I would like the drive to be the "home" for my linux image for > my blade server. Use what works for you. Me, I use /mnt for "temporary" mount points. Things like floppies and CDs, flash drives, network filesystems I'm temporarily mounting for whatever reason, that sort of thing. In organizations (companies), I try to build an org-wide directory structure under a top-level name. For example, if I work for Acme Products, I'd have off the root, and structure things under there. If I was in the materials lab at Acme, and I was building a blade server called "darkstar", I might use . If I was hosting multiple system images, or thought I might do so, I might use or something like that. This has the advantage in that the corporate IT resource server can be mounted under , centralized home directories under , the software lab's source code under , or whatever. You get a consistent structure everywhere. That may be total gigantic overkill for what you're doing. Maybe you just want , or . The FHS that V. Alex Brennen references actually states that is for temporary mounts; the location for stuff you're serving out would be under . So maybe or whatever. I would recommend against just , because then when you get your second blade server, confusion occurs. Use unique names. But use what works for you. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Adding a new drive / fstab
On Wed, Jul 9, 2008 at 12:28 PM, Drew Van Zandt <[EMAIL PROTECTED]> wrote: > On 7/9/08, Labitt, Bruce <[EMAIL PROTECTED]> wrote: >> > Anyone got any >> > suggestions? Pitfalls on how I am thinking about things? >> > > > It seems to me that using any of the "traditional" mount points in this > situation is somewhat inappropriate; the new drive is intended primarily as > a resource for another machine. Given that, Thomas' suggestion of > /bladeimages is a pretty sensible one. I tend to mount shared net drives on > mountpoints like "/share", or mount a RAID on /raid, make a directory called > "share" on it, and share that directory. It makes it obvious what physical > resource is associated with the mountpoint, and you can use symlinks to > organize things in a logical sense. > > I dislike the /mnt suggestion because to me, /mnt is for a foreign > filesystem, e.g. something that might be removed. On the blade server, > however, I'd probably mount the shared net filesystem under /mnt, for > reasons mentioned in VAB's reply. > Just to throw a few more wrenches... Solaris uses /export for file systems that will be exported on NFS. /export/home is for home directories. /opt is for 3rd part packages. /mnt and /home are used by automount to mount NFS file systems from servers I'm using /misc on my Linux boxes where Solaris has /mnt /media on Fedora linux is for CDs, USB drives. I think Ubuntu uses it too. Solaris uses /cdrom, /floppy and probably /usb. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Adding a new drive / fstab
> > On 7/9/08, Labitt, Bruce <[EMAIL PROTECTED]> wrote: > > Anyone got any > > suggestions? Pitfalls on how I am thinking about things? > It seems to me that using any of the "traditional" mount points in this situation is somewhat inappropriate; the new drive is intended primarily as a resource for another machine. Given that, Thomas' suggestion of /bladeimages is a pretty sensible one. I tend to mount shared net drives on mountpoints like "/share", or mount a RAID on /raid, make a directory called "share" on it, and share that directory. It makes it obvious what physical resource is associated with the mountpoint, and you can use symlinks to organize things in a logical sense. I dislike the /mnt suggestion because to me, /mnt is for a foreign filesystem, e.g. something that might be removed. On the blade server, however, I'd probably mount the shared net filesystem under /mnt, for reasons mentioned in VAB's reply. --DTVZ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Adding a new drive / fstab
On Wed, 2008-07-09 at 11:50 -0400, Labitt, Bruce wrote: > In the endless pursuit of upgrading this machine I have added a hard > drive to my computer. I have used fdisk to create a linux partition to > the whole disk. I made the disk use the ext3 file system. > > So now for fstab. What is the philosophy for creating an entry? At > this point I'm not sure what the mount point should be. /home sounds > ok, but I would like the drive to be the "home" for my linux image for > my blade server. I think the best thing to do may be to create a mount point for the drive under the '/mnt' directory. Perhaps, given the usage plan you described for this disk '/mnt/sys_imgs' (or something similar) is appropriate. A very long explanation why: Many years ago, when new *nix systems were open popping up rather frequently, there was an attempt to create a unified standard (which eventually became the POSIX standard). One of the core components of that standard was the file system (layout) structure. The file system layout structure standardization was undertaken in order to make it easier for people who found themselves working on many very different flavors. Those people included developers who were creating applications, for companies training users, and also system administrators. The portion of the standard consisted of many points including the following: - /tmp used by users for temporary user data - /var/tmp used by applications for temporary data - /bin, /sbin, /lib used for programs necessary for boot - /usr/bin, /usr/sbin, /usr/lib used for OS programs not necessary for boot and user installed software - /var variable data - /mnt used to mount remote file systems and directories that were not part of the standard. The idea was that if you had to perform an operating system upgrade, you knew you would not step on the 3rd party vendor program you just installed at some user's request. Likewise, while installing a program for that user you know you didn't have to worry about it installing over a program in '/bin' that you need to boot your system. This was extremely useful because vendor apps often required different versions of the same libraries and programs than the system required to boot. The idea behind using '/mnt' was that it would be easy for an admin to avoid backing up a number of file systems twice if they ware remotely mounted under a single directory by excluding that directory with the tar argument for doing just that. A sysadmin would also know that a disk error was with a secondary disk and not one of the primary OS disks that could render the system unbootable. So, that's why I suggest using a directory under '/mnt'. Although, a directory under '/usr/share' or '/usr/local/share' may also be appropriate. Here is the wikipedia page on that portion of the POSIX Standard (the FHS: Filesystem Hierarchy Standard): http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard - VAB - V. Alex Brennen [EMAIL PROTECTED] Senior UNIX Systems Administrator MIT Libraries E25-131 x3-9327 http://vab.mit.edu/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Adding a new drive / fstab
On 7/9/08, Labitt, Bruce <[EMAIL PROTECTED]> wrote: > So now for fstab. What is the philosophy for creating an entry? At > this point I'm not sure what the mount point should be. /home sounds > ok, but I would like the drive to be the "home" for my linux image for > my blade server. The idea is that this box is the file server for my > blade. The blade will boot from my file server. The blade is > effectively a compute engine running linux. The big datafiles that > result from computation will reside on my file server. Anyone got any > suggestions? Pitfalls on how I am thinking about things? /bladeimages ? :-D Thomas -- -- Thomas ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Adding a new drive / fstab
In the endless pursuit of upgrading this machine I have added a hard drive to my computer. I have used fdisk to create a linux partition to the whole disk. I made the disk use the ext3 file system. So now for fstab. What is the philosophy for creating an entry? At this point I'm not sure what the mount point should be. /home sounds ok, but I would like the drive to be the "home" for my linux image for my blade server. The idea is that this box is the file server for my blade. The blade will boot from my file server. The blade is effectively a compute engine running linux. The big datafiles that result from computation will reside on my file server. Anyone got any suggestions? Pitfalls on how I am thinking about things? Thanks -Bruce ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
