Find the answer to your Linux question:
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 11
Hello, I recently came across an article (see kb.parallels.com/1410) that was explaining how to create the /tmp directory as a separate partition from the root partition/filesystem but the method of ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Aug 2011
    Posts
    6

    Logical partitioning for directories in the root filesystem


    Hello,

    I recently came across an article (see kb.parallels.com/1410) that was explaining how to create the /tmp directory as a separate partition from the root partition/filesystem but the method of allocating the partition was foreign to me.

    The suggested commands were (as given at the site above):

    Code:
    # mkdir /filesystems
    # dd if=/dev/zero of=/filesystems/tmp_fs seek=512 count=512 bs=1M
    # mkfs.ext3 /filesystems/tmp_fs
    And in /etc/fstab specifying the mount as:
    /filesystems/tmp_fs /tmp ext3 noexec,nosuid,loop 1 1

    Now I can understand using a partitioning tool like fdisk or parted to create a new logical partition (say /dev/sda6), formatting it with ext3, and then mounting the new partition as /tmp to create a separate filesystem for the /tmp folder, because it is a 'registered' partition in the /dev folder.

    What I don't understand is what creating a new folder with mkdir (/filesystems) under the root partition and then using dd to write 512M under it will do to the specified tmp_fs directory (or is tmp_fs a file?) to "make" it a partition. And also, does that new partition - and the ext3 filesystem - written to /filesystems/tmp_fs 'register' as an sdaX logical partition number/device in the /dev directory? If so does it do so as soon as you execute the dd command? If not then how is a partition created since most partitioning tools require a "device" path.

    This is most likely a misunderstanding of the partitioning concepts in Linux and/or the terminology used on my part, but I am curious how you can just create a partition in a random subdirectory without even specifying the harddrive you are wanting the partition on (unless it just chooses the one you are currently on) and just allocate space to it using the dd command that makes/transforms it from a regular directory (or file?) into something that can be used as a partition. Also wouldn't the /filesystems subdirectory and its contents still be on/part of the root file system?

    Would someone be so kind as to enlighten me please? All the documentation I have read about this always uses a /dev/sdaX example, so you can see why that would not help with the above example.

    Thanks!
    Last edited by cybershark5886; 08-24-2011 at 07:11 PM.

  2. #2
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,221
    - tmp_fs is a regular file
    - it is located in the directoy /filesystems
    - the dd writes exactly 512MByte to that file. It doesnt really matter, what you use to fill up the file. You can also use cat, bash redirect, <whatever you want>
    dd is convenient, because you can control the size quite nicely and /dev/zero is fast.
    - mkfs.ext creates a filesystem within that file. Who said, you need a device for that?
    - then this filesystem within a file is mounted. Look for the loop parameter in "man mount".

    And yes, you dont get additional space. Quite the contrary, as you expected: that tmp_fs takes space from the root file system.
    You must always face the curtain with a bow.

  3. #3
    Linux Guru
    Join Date
    Nov 2007
    Posts
    1,746
    or is tmp_fs a file?
    Yes, it's a file. Now that it's a file with a size limit (512MB), tmp cannot grow and fill the root filesystem.

  4. #4
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,221
    good point
    It can be a way to restrict /tmp without reinstalling/repartitioning
    You must always face the curtain with a bow.

  5. #5
    Just Joined!
    Join Date
    Aug 2011
    Posts
    6
    Quote Originally Posted by Irithori View Post
    - tmp_fs is a regular file
    - it is located in the directoy /filesystems
    - the dd writes exactly 512MByte to that file. It doesnt really matter, what you use to fill up the file. You can also use cat, bash redirect, <whatever you want>
    dd is convenient, because you can control the size quite nicely and /dev/zero is fast.
    - mkfs.ext creates a filesystem within that file. Who said, you need a device for that?
    - then this filesystem within a file is mounted. Look for the loop parameter in "man mount".

    And yes, you dont get additional space. Quite the contrary, as you expected: that tmp_fs takes space from the root file system.
    Interesting. So would you even regard that as a logical "partition" or as more of a file system formatting trick? If it is to be regarded as a proper "partition" that would kind of screw up the whole concept of primary partition vs. extended partition (both physical), where the latter (say /dev/sda4) cannot be mounted proper but rather the logical partitions that are created on it (sda5, sda6, etc.), wouldn't you say? But what I'm saying is that that kind of trick could be done even on on a non-extended (primary) partition. That circumvents the whole idea of an extended partition does it not? Just curious.

  6. #6
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,221
    Well, you cant boot from such a partition.
    Also it will lower the performance, as you introduce another layer.

    But the 4 primary partitions are a limitation of hardware (disks) and bios.
    Not a limitation of todays operating systems.

    Today, there is gpt partition table (afaik max 128 partitions) and efi as "bios".
    You must always face the curtain with a bow.

  7. #7
    Just Joined!
    Join Date
    Aug 2011
    Posts
    6
    Quote Originally Posted by Irithori View Post
    Well, you cant boot from such a partition.
    Also it will lower the performance, as you introduce another layer.

    But the 4 primary partitions are a limitation of hardware (disks) and bios.
    Not a limitation of todays operating systems.

    Today, there is gpt partition table (afaik max 128 partitions) and efi as "bios".
    That's a good point about the performance cost. Am I to assume that logical partitions on a physical extended partition don't have any similar performance hits though (compared to if it were rather a primary partition)? Basically is there any difference in performance between accessing a primary and a logical partition? I guess I've never really thought about it before.

    But creating a file system inside a file is a completely new idea for me (apart from working with virtual machines - is it comparable to creating a VM virtual disk?). I wonder if you can format it with a different file system than the one the file itself is sitting on (like FAT16/32 in the file stored on an ext3 root file system). It's an interesting trick that may come in handy one day though.

  8. #8
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,221
    No, there is no performance difference between a primary and a logical partitions.
    It is just a convention on how to access a physical disk.

    As for filesystem in a file:
    As I said, here you have another layer.
    So if anything, it is slower than the underlying fs.

    Yes, it is a trick and my recommendation would be to treat it like that.
    Usually one wants to avoid complexity and unneeded parts in a system setup.

    The fs in that file can be anything you want.

    Virtual disks of vms are more or less that (with added structures to support snapshots, etc)
    You must always face the curtain with a bow.

  9. #9
    Just Joined!
    Join Date
    Aug 2011
    Posts
    6
    Quote Originally Posted by Irithori View Post
    No, there is no performance difference between a primary and a logical partitions.
    It is just a convention on how to access a physical disk.

    As for filesystem in a file:
    As I said, here you have another layer.
    So if anything, it is slower than the underlying fs.

    Yes, it is a trick and my recommendation would be to treat it like that.
    Usually one wants to avoid complexity and unneeded parts in a system setup.
    Thanks for your responses. They have been helpful. I have one last question though, which I edited my above post to include. Would that type of a file be comparable to a VM virtual disk file, and could you use any kind of file system regardless of what fs the file itself is stored on?

  10. #10
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,221
    yw.
    I already answered in my edited post above
    You must always face the curtain with a bow.

Page 1 of 2 1 2 LastLast

Posting Permissions

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