[lfs-support] What Is "The" LFS Partition?

Henrik /KaarPoSoft henrik at kaarposoft.dk
Tue Nov 6 12:10:02 PST 2012


On 11/06/12 19:59, Feuerbacher, Alan wrote:
> Seriously, this is among the most useful articles -- and I do mean 
> "article" -- that I've read about this topic. Thank you! 
Thank you for the nice words, I just hope it can help you...
>> Suggestion: Stick to MBR for now!
>> When you have learned how it works, you may try out GPT.
> Now I'm waffling about what to do, given that I've gone to the trouble of learning about and installing both GPT and LVM systems. I feel a lot more comfortable with the terminology and concepts now, given all the help from this list and other reading.
If you really understand LVM, fine, go ahead!
As for GTP, maybe I am just a bit old-fashioned.
I use the legacy MBR partitioning because "everyone" understands it.
If you and your systems understand GPT, go ahead!
[ I guess I will use GPT for my next system... ]
>> [...]

>> When you format a block device as a filesystem (e.g. with mke2fs), the
>> first few bytes of the (block device seen as an) array of bytes gets
>> initialized with some "magic" values.
>>
>> When the "mount" command is used on a block device (e.g. "mount
>> /dev/sda7 /mnt"), it looks at the first few bytes for those "magic"
>> values, to figure out which type of filesystem is there. It then
>> instructs the kernel to interpret the block device as a filesystem of a
>> certain kind.
> So "mount" essentially associates a physical location in a particular partition (say, the first few magic bytes of /dev/sda7) with a directory name ("/mnt"), no?
Yes.
> Why does one have to create a directory with that name before executing the "mount" command? Just because that's the traditional way mounting is done? Or are there more basic reasons? In other words, why could the "mount" command not create an actual directory (in the sense that "/usr" is an actual directory) if the directory requested in the mount command (say, mount /dev/sda7 /mnt/lfs) does not exist? I'm asking because this has caused me no end of trouble, because I've not seen in any documentation the requirement that said directory exist before doing the mount command.
I cannot tell you the history behind this; but this is how it is:
mount DEV DIR
requires that DIR exists and is a directory.
>> Suggestion: Stick with ext4 until you understand more!
>>
>>
>> 5) LVM
>>
>> LVM is great in many situations, however:
>>
>> Suggestion: Do not play with LVM until you understand the basics!
> But LVM is touted as being easier to deal with than the older system. Is that not the case?
>
> For example, last night I managed to make GPT partitions and an LVM filesystem on my new hard disk (earlier today I emailed this list with a blow-by-blow account of doing this), based only on material from Net searches. Now, if I can do that, I would think that the process is substantially easier than the old methods.
It might me that GPT is easier than MBR-partioning.
But whatever you have to do and understand after venturing into LVM, you 
also have to do and understand before.
That is why I suggested looking into a basic system before venturing 
into LVM.
>> 8)  DISCLAIMER AND MY 5 CENTS
>>
>> I have build LFS and BLFS a couple of times, and now created
>> http://kaarpux.kaarposoft.dk/
> Pretty cool!
Yes! Check it out...
It is somewhere between LFS/BLF and ArchLinux
>
>> On my disk I usually have
>> - possibly a Windows partion
>> - a swap partition
>> - one or two partitions with Fedora/Gentoo or other "stock" linux.
>> - several partitions for several LFS/BLFS/KaarPux systems
>> -- each of those partitions are ususally 64G to fit a whole system
>>      on one partition/filesystem
> Something along those lines is what I'd like ultimately to do. But my wife keeps telling me I should get a Mac. :-)
Good advice (-:
[ I mean, not the Mac as such, but doing what your wife tells you (((-; ]
>> Although using several partitions for one system (e.g. /, /boot, /usr,
>> /var, /opt) has it's merits - in particular if you have a power break
>> and the filesystems are broken -
> Can you elaborate?
This is very much biased on my own experience, and very simplified.
Others may have differet opinions / facts / etc...

Functionally, every filesystem is a map from path to content.

But, the "path" is different in each file system, in particular when it 
comes to character encoding.
Some systemes are use mostly ASCII path names (with DOS pages thrown 
in): FAT*
Some systems use utf-8 (e.g. ext*).
This is a big mess, and I shall try not elaborate here, as I am still 
confused.
In any case, read this:
http://www.joelonsoftware.com/articles/Unicode.html
(Not related to filesystems, but to encoding).

Also, content is different:
Every filesystem allows a sequence of bytes as content.
But some filesystems (like ext*) allows symbolic links as well, FAT* 
does not.
And some systems (like NTFS) allows multiple "streams" inside a file.
Again, too much to cover here.

Then there are differences in how to store data (zfs may compress data),
and meta-data differences: e.g. ufs, zfs, btrfs may allow you to create 
snapshots.

And there are differences in how big a partition a filesystem may handle.

Then there are diffences as to how to handle "disruptions".
What if the kernel panics? What if the power breaks?

This is really what my comment was about.

A FAT filesystem has no protection against "disruptions".
Remember the old DOS system? Power break meant hours of file system 
testing, and a mess afterwards.

Different filesystems have more or less resilience to "disruptions".

Again, too much to cover here, but ext4 can have journalling...

If you follow my advice and have only ONE partition for 
LFS/BLF/KaarPux/...whatever...
if you have a power break or similar and that partition is damaged (an 
cannot be repaired) you have lost.

However, if you have several partitions, it may be that you can mount 
/boot and boot the kernel,
then mount / and get a system running.
Then if, say, /usr or /opt is damaged, you may have a chance of 
recovrering it.

Now, that being said, I still suggest a single partion "strategy":
I have several partitions with different stages of LFS/BLFS/KaarPux,
and if one is fried (e.g. by power failure) I just boot another.

I have a server and a firewall, i.e. "production systems",
and there I use several partitions, and thus they always come up after 
powerfail.

But for my LFS/BLFS/KaarPux system (desktop) I have just one partition 
per system.


>> I now find it much easier to just have
>> the whole system on one partition.
> Easier mainly because you don't have to create a lot more partitions?
Yes, and because I do not have to MANAGE a lot of partitions afterwards.

/H



More information about the lfs-support mailing list