No announcement yet.

Fedora 17 Moves Forward With Unified File-System

  • Filter
  • Time
  • Show
Clear All
new posts

  • energyman
    oh and their Myth10/Fact pair is a blatant lie. But what do you expect...

    Leave a comment:

  • energyman
    Improved compatibility with GNU build systems: The biggest part of Linux software is built with GNU autoconf/automake (i.e. GNU autotools), which are unaware of the Linux-specific /usr split. Maintaining the /usr split requires non-trivial project-specific handling in the upstream build system, and in your distribution's packages. With the /usr merge, this work becomes unnecessary and porting packages to Linux becomes simpler.

    as a reason. Are they serious? That one is one of the dumbest reasons.

    For everybody out there asking why:
    who is using autoconf/automake the most?

    and who isn't?

    For me the move sounds idiotic. The split has always been for a very good reason.

    / contains everything you need to boot the system and put everything in place.
    Mount the rest
    Start the services.

    Nice and clean.

    Something fucked up /usr? No problem, at least you could boot and repair it. Now you need a livesystem. Oh, that one is slightly incompatible with the system you need to repair. Tough luck old boy!

    Leave a comment:

  • GreatEmerald
    Originally posted by Aquous View Post
    Why move / -> /usr? Why not /usr -> / with /usr becoming a symlink to /?
    Another reason not mentioned in the FAQ is mounting. If you put /bin into a separate partition, it will be rather useless, since it requires /lib to run properly anyway. While /usr contains all of the requirements already, so it could be mounted on a mostly self-sufficient partition/disk and therefore possibly increase performance.

    Leave a comment:

  • allquixotic
    I'm all for this in general, but I use so much hand-compiled software, legacy software, etc., that it's going to be a royal pain. Basically I'm gonna end up having /bin and /lib and blah anyway, and end up symlinking them from /usr so that certain things will compile (especially stuff that doesn't use autoconf).

    Leave a comment:

  • bachinchi
    And the other guys...

    What do Debian and SUSE people think of this?

    Leave a comment:

  • oliver
    I've read the freedeskop wiki, I've read the 'explanation' about small disks and what not.
    The historical justification for a /bin, /sbin and /lib separate from /usr no longer applies today. (More on the historical justification for the split, by Rob Landley) They were split off to have selected tools on a faster hard disk (which was small, because it was more expensive) and to contain all the tools necessary to mount the slower /usr partition. Today, a separate /usr partition already must be mounted by the initramfs during early boot, thus making the justification for a split-off moot. In addition a lot of tools in /bin and /sbin in the status quo already lost the ability to run without a pre-mounted /usr. There is no valid reason anymore to have the operating system spread over multiple hierarchies, it lost its purpose.
    I don't ever heard of that being the reason for the split. Faster slower disks? The 'explanation' actually puts it as
    "Ken and Dennis leaked their OS into the equivalent of home because an RK05 disk pack on the PDP-11 was too small"
    Which makes some sense I suppose, and may be true back then, but found more adequate meaning later. I'm sure everybody has forgotten abou the 'FHS' but it does still exist. This what it has to say about /bin.
    Chapter 3. The Root Filesystem

    The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system.

    To boot a system, enough must be present on the root partition to mount other filesystems. This includes utilities, configuration, boot loader information, and other essential start-up data. /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems.

    To enable recovery and/or repair of a system, those utilities needed by an experienced maintainer to diagnose and reconstruct a damaged system must be present on the root filesystem.

    To restore a system, those utilities needed to restore from system backups (on floppy, tape, etc.) must be present on the root filesystem.
    No myth here, a mere 'fact' if you may call the FHS that. And it makes sense. Yes, an initramfs can fulfil this task. But I guess the sloppyness of fedora would mean the initramfs would grow to 450mb in a few years time ..

    Myth #9: The /usr split is useful to have a minimal rescue system on the root file system, and the rest of the OS on /usr.

    Fact: On Fedora the root directory contains ~450MB already. This hasn't been minimal since a long time, and due to today's complex storage and networking technologies it's unrealistic to ever reduce this again. In fact, since the introduction of initrds to Linux the initrd took over the role as minimal rescue system that requires only a working boot loader to be started, but not a full file system.
    So because fedora's / is ~450MB it is fact that it hasn't been minimal? On my gentoo server it's about
    du -d 1 -h / -x
    16K     /lost+found
    4.0K    /home
    4.0K    /opt
    22M     /lib64
    4.0K    /var
    11M     /sbin
    16M     /boot
    4.0K    /mnt
    0       /dev
    2.6M    /lib32
    0       /sys
    4.0K    /media
    11M     /bin
    13M     /etc
    4.0K    /usr
    108K    /chroot
    0       /proc
    11M     /root
    4.0K    /tmp
    86M     /
    So that's about 75MB (/root has some stuff i need to move). Actually, 68MB as /etc contains a .git tree worth 7MB. Pretty reasonable and minimal. And it can do everything it is supposed to do to recover my system. So this says more about fedora, than about linux in general, or is gentoo the only one that keeps it as it should?

    And I do actually have an initramfs, it contains mdadm to bring up my raid1 and raid5's since it is no longer supported to have the kernel do it.

    Myth #10: The status quo of a split /usr with mounting it without initrd is perfectly well supported right now and works.

    Fact: A split /usr without involvement of an initrd mounting it before jumping into the root file system hasn't worked correctly since a long time.
    Lie. Sure, in fedora it doesn't work, probably not in ubuntu either. But on my gentoo box, it works perfectly fine, to recover and repair the system of course, which what this split is for!! Even if my initramfs fails and i only have the kernel, I can still boot from half my raid1 and still repair my system!

    So all in all, this move seems more like 'Fedora's / is a mess and isn't properly split as it should, lets just move everything to /usr and where it should be anyway, and do our own thing.'

    I'm surprised nobody mentioned the FHS in the 'explanation' mailing-list thread. Also, I'm supprised the mentioning of /usr/local and /opt. As far as I understood, from the FHS obviously, is that /usr/local where applications that where installed locally on the host, say if /usr where on nfs. /opt was for 3rd party (closed src) applications and other 'add-ons'. I can actually even see an /opt/local, if /opt would have been an nfs share, but 1 system would be allowed to install a specific 3rd party package.
    Last edited by oliver; 27 January 2012, 07:19 PM.

    Leave a comment:

  • Chewi
    I was initially against this and I felt that not enough consideration was being given to why they were split in the first place. I have now read this and hastily switched sides.

    Leave a comment:

  • MrRtd
    Unified File-System

    This seems to make a lot of sense, and I hope it works out well, and is adopted by all Linux distro's.

    Leave a comment:

  • cl333r
    Folks please at least read the explanation before suggesting or complaining.

    Leave a comment:

  • DaemonFC
    Myth #11: Instead of merging / into /usr it would make a lot more sense to merge /usr into /.
    Fact: This would make the separation between vendor-supplied OS resources and machine-specific even worse, thus making OS snapshots and network/container sharing of it much harder and non-atomic, and clutter the root file system with a multitude of new directories.
    I suggest that people at least TRY to read the FAQ.

    Leave a comment: