Find the answer to your Linux question:
Results 1 to 8 of 8
I'll come right out and say it that I don't understand the Linux Filesystem Logic although I have studied it quiet a bit. I'm currently studying grub but my question ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux Newbie theKbStockpiler's Avatar
    Join Date
    Sep 2010
    Location
    Upstate NY
    Posts
    205

    Catch 22 with Linux file hierarcy question.




    I'll come right out and say it that I don't understand the Linux Filesystem Logic although I have studied it quiet a bit. I'm currently studying grub but my question is...

    How can a directory mount a storage device when the directory is part of the storage device?

    The directory is data on the storage device but somehow it operates with out being connected to it s own data. See what I mean!

    Any enlightening Info. would be appreciated!

  2. #2
    Linux Enthusiast meton_magis's Avatar
    Join Date
    Oct 2006
    Location
    arizona
    Posts
    699
    Quote Originally Posted by theKbStockpiler View Post


    I'll come right out and say it that I don't understand the Linux Filesystem Logic although I have studied it quiet a bit. I'm currently studying grub but my question is...

    How can a directory mount a storage device when the directory is part of the storage device?

    The directory is data on the storage device but somehow it operates with out being connected to it s own data. See what I mean!

    Any enlightening Info. would be appreciated!
    you have to separate REAL filesystems (files on your hard drives) from LOGICAL filesystems.

    When someone says filesystems they can mean several things.

    1, the Linux filesystem, starting with / and continuing on to whatever file you want to access.

    2, a partition or logical volume that can be mounted onto the Linux filesystem.

    3, the filesystem type (such as ext3, ntfs, vfat) that is applied to a partition, and which files are saved onto.

    A mountpoint is the directory on the linux filesystem (number 1) where a filesystem (number 2) has been mounted onto, joining it into the linux filesystem (number 1).

    number 1 is a LOGICAL filesystem, it doesn't have to exist as a disk, it can exist in ram alone, and be populated from files off of a CD (such as when you run a livecd environment.) number 2 is a REAL or hard filesystem, that contains files on a disk. Number 2 will be the same on all Linux computers, and never change unless you save the files to disk. Number 3 is not really a filesystem, but a formatting type, but is referred to as a filesystem at times.

    /dev and /proc are both logical filesystems. They don't really exist on disk, but are generated by the kernel to make devices and processes human viewable and accessible. When you mount /dev/sda2 to /home, you are mounting a logical device (that maps to the second partition of the first SCSI (or sata) disk) to the filesystem.


    I hope I haven't confused you more. It's not really something that's easy to understand with how many uses 1 word gets.
    New to the internet, technical forums, or the hacker / open source community??
    Read this to learn good posting habits http://www.catb.org/~esr/faqs/smart-questions.html

    RHCE for RHEL version 5
    RHCT for RHEL version 4

  3. #3
    Linux Engineer hazel's Avatar
    Join Date
    May 2004
    Location
    Harrow, UK
    Posts
    1,198
    Quote Originally Posted by theKbStockpiler View Post

    How can a directory mount a storage device when the directory is part of the storage device?

    The directory is data on the storage device but somehow it operates with out being connected to it s own data. See what I mean!
    Well, you can't mount a partition on itself for precisely that reason! You can only mount one partition on another. The directory which acts as a mountpoint has to be on a different device from the data. While the mount lasts, the mountpoint directory becomes an alias for the root directory of the mounted device; any data in the directory itself becomes invisible for the duration.

    It's easy to illustrate this. Create a mountpoint under /mnt and put a few rubbish files in it. You can list these files and work with them. Now mount another device on this directory. When you list the directory, you no longer see the files you created; instead you see the files on the mounted device. Unmount the device and your files become visible again.
    "I'm just a little old lady; don't try to dazzle me with jargon!"

  4. #4
    Linux User sgosnell's Avatar
    Join Date
    Oct 2010
    Location
    Baja Oklahoma
    Posts
    464
    In Linux, everything is a file. It may only be a logical file, but it's treated no differently for being logical. A device, such as a CD drive, is a file to Linux, as is anything else. It's just a way of looking at things, but it can be confusing to anyone who has known only Windows.

  5. #5
    Linux Newbie theKbStockpiler's Avatar
    Join Date
    Sep 2010
    Location
    Upstate NY
    Posts
    205

    I'm starting to get the idea

    The Linux file system is abstacted like it is all on the hard drive so /.../ whatever does not mean ANYTHING! when I look at /home/user/ this implies a connection which there is not. This is just so the thing that manages inodes has an argument.

  6. #6
    Linux Engineer hazel's Avatar
    Join Date
    May 2004
    Location
    Harrow, UK
    Posts
    1,198
    You seem to be compaining because Linux (like all unix systems) has an integrated filesystem rather than a separate tree for each disk as Windows does. But why is that a fault? Surely it's just a different way of doing things. Many users consider it an improvement as they don't need to know exactly what disk a directory is on.

    An integrated filesystem means that if your disk gets over-full and you add a new one, you can hive off a directory tree onto that disk without having to change all your pathnames. Admittedly that's not so important now when disks have become so huge, but it was once a valuable advantage. I doubt if the original UNIX designers did it this way just so that the inode system would work!
    "I'm just a little old lady; don't try to dazzle me with jargon!"

  7. #7
    Linux Newbie theKbStockpiler's Avatar
    Join Date
    Sep 2010
    Location
    Upstate NY
    Posts
    205

    I have most of this ironed out. I

    The "Hard File Systems/Logical File Systems approach is right on but is to logical to find from a search engine on the web. If you Google (Linux File System) you just get the useless notation that a Bash srcipter understands. If you Google (Unix File System) you can find articles that go past "user readable notation" and gets more into the nuts and bolts of things.

    Studying the (Linux File System) from a (META DATA) angle is the only way.UNIX INTERNALS
    Last edited by theKbStockpiler; 11-08-2010 at 01:51 PM.

  8. #8
    Linux Enthusiast meton_magis's Avatar
    Join Date
    Oct 2006
    Location
    arizona
    Posts
    699
    Just think of it this way. The filesystem doesn't "exist" anywhere. It is a logical representation given by the kernel. You could just as easily take a disk formated with vfat, and represent it as a list of files with no directory structure. In fact, on mainframe systems (thinking IBM Z/OS here) there is no technical filesystem how unix and windows has it. You don't have files, you have named data sets. You refer to absolute names always. there is no idea of a "working directory", relative paths, or multiple devices. You have 1 big storage pool (I'm simplifying) that all files are dumped to, and there is no logical ordering of files. This worked, because it has many ways of keeping track of files.

    Unix doesn't keep track of files across reboots. It recreates the filesystem each time it's booted (or even when disks are (un)mounted. It gives you a logical representation, but there is no such thing as a file, only inode tables, and a series of bytes. When a disk is mounted, it looks at the inode (or file allocation table, AKA FAT) and figures out what "files" exist.

    It is confusing, but it's not something you need to know how or why it works, just that it does, and learn how to read what it gives you.


    BTW, that link you posted on UNIX internals is fascinating. Thanks for sharing. I'll have to look it over when I have time.
    New to the internet, technical forums, or the hacker / open source community??
    Read this to learn good posting habits http://www.catb.org/~esr/faqs/smart-questions.html

    RHCE for RHEL version 5
    RHCT for RHEL version 4

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •