Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
GNU is Not Unix Operating Systems Software Unix

The Hurd Gets Support For Large Filesystems 58

latroM writes "Finally, after many years of waiting, the Hurd has got support for partitions larger than 2GB. The patch is told to be very stable and its development was started about a year and a half ago. Michael Bank writes: 'I hacked the Debian package so far that I make it build a statically compiled ext2fs with Ogi's patch (20041029) for partitions > 2GB. For now, I decided to just copy libpager, libdiskfs and ext2fs to libpager-ogi, libdiskfs-ogi and ext2fs-ogi, apply his patch and dump the result as a new patch. Another patch modifies the Makefiles accordingly.' I did some basic tests with those packages and they work fine for me so far. Any comments on how they work for people and how to possibly improve the packaging and integration of the patch are very welcome."
This discussion has been archived. No new comments can be posted.

The Hurd Gets Support For Large Filesystems

Comments Filter:
  • by Anonymous Coward on Wednesday December 08, 2004 @09:45AM (#11031707)
    The mighty HURD has >2 GB filesystem support, and Longhorn still isn't out! Who's laughing now? I ask: Who is laughing now?
  • Hurd development (Score:2, Interesting)

    by Anonymous Coward
    According to the Hurd's "What's New [gnu.org]" page, nothing new has happened since August 2003.

    Doesn't exactly look as if development is proceeding at a roaring pace.
    • by Anonymous Coward
      Yeah, that's because the guys concentrate on coding, not on web pages.
    • Re:Hurd development (Score:2, Informative)

      by Anonymous Coward
      I posted the same thing the last time a HURD story came up. Turns out they have trouble maintaining websites and the links to the mailing lists are outdated, there are new mailing lists lurking somewhere. At the moment, there isn't much visible progress as they are busy porting from one microkernel to another.
      • by Anonymous Coward

        Turns out they have trouble maintaining websites...

        And they're trying to code a kernel?

        • Actually the Hurd pages are in CVS and AMS (the guy who normally does the web site edits) had his ability to edit the pages revoked while Marcus was busy and didn't notice until recently (AMS can now edit pages again, hooray).

          Coding and maintaining web pages are different tasks. If you read the mailing lists and hang out on the IRC channel you'll be kept up to date.

      • Maybe the linked debian-hurd list is one of those still-living mailing lists. I bet most hurd developers are on it...
  • by pb ( 1020 ) on Wednesday December 08, 2004 @09:55AM (#11031801)
    You've been waiting for The HURD? Oh, whoops, I've been using Linux. It's quite nice, I hear RMS uses it to host webpages and stuff. Perhaps you should try it!
  • by RAMMS+EIN ( 578166 ) on Wednesday December 08, 2004 @09:55AM (#11031803) Homepage Journal
    Large filesystem support...check

    Let's see what we still need...

    Out of memory
    Segmentation fault
  • Evolution of HURD (Score:3, Interesting)

    by mhesseltine ( 541806 ) on Wednesday December 08, 2004 @09:59AM (#11031839) Homepage Journal

    While Linux, Windows, etc. have had 2Gb filesystems for a long time, it is nice that HURD supports larger files now.

    I'll probably never use it, but I respect the HURD crew for continuing to stay committed to their project, despite HURD being so far behind other kernels.

    • I agree, there are so many open source projects that fall a little behind of other similar projects and *poof*, it gets abandonded. Just look at how many dead projects there are on Sourceforge.
      • Alternatively..

        Instead of starting up all of these projects that are well known to fall into neverland or trickle like rain in the desert, it would be great if more people wouldn't, and instead get behind a single project in order to keep it alive.

        Forks or fresh code that parallel each other idea-wise only go so far (generally), but patches and branched development can live forever. ;)
    • it is nice that HURD supports larger files now.

      s/files/filesystems/

      It may or may not support large files yet, that could be another few years :)
    • by siskbc ( 598067 )
      I'll probably never use it, but I respect the HURD crew for continuing to stay committed to their project, despite HURD being so far behind other kernels.

      Kind of like reinventing the wheel, only you just finally made one of stone while everyone else is driving cars. And people are offering you free cars. Don't know what the point is, other than their ideology. But then, for GNU, ideology is the end and the means.

  • All this patching makes my hurd heart.. erm, head hurt.
  • Future (Score:2, Funny)

    by zemoo ( 582445 )
    Can't believe no one's said this yet:

    Large filesystems are great ... but will it run Duke Nukem Forever?
  • Next Up... (Score:4, Funny)

    by DesScorp ( 410532 ) on Wednesday December 08, 2004 @11:09AM (#11032591) Journal
    ...they're replacing punch cards with a monitor and keyboard. Oooohhhh! An I hear they've got....shhhh...Floppy Drive support on the way!

    They've GOT to fix that 640K thing though...like, gag me with a spoon...
  • I'm relatively uninformed on what a "GNU" system looks liken these days versus an average "GNU / Linux" system (to use the parlance preferred by the HURD herd).

    If I'm intruiged in trying out "GNU" what is the best way to get and install it? Is there a "distribution" of a completely GNU system running the HURD with an installer that's user-friendly and fairly straightforward yet? Or is a totally GNU system still in the state that "SNU / Linux" was back when lots of reading and domain knowledge was require
    • Debian has a HURD distribution [debian.org]. The installation doesn't sound too bad if you have an existing Linux (or whatever) system and an adequate free partition, and are already using grub. I haven't been insane enough to try it, though.
    • by albalbo ( 33890 ) on Wednesday December 08, 2004 @11:37AM (#11032937) Homepage
      You can get Debian GNU/Hurd, this is the easiest way to install a GNU system. It looks much like Debian GNU/Linux though - in fact, very similar. The GNUishness seems to affect more than the Linuxness ;)

      In terms of differences - Hurd has very different models of doing things. For example, non-root users can effectively mount filesystems if they have all the permissions needed. There are these things called "translators" which is a bit like FUSE or the other user-space filesystem things you get - essentially, generating a filesystem via a program, so you could mount anything you can script really.

      There are lots of other interesting differences. Hurd isn't terribly similar to Linux, and does allow you to do some rather cool things.
      • On the surface Linux and HURD are very similar. That's because most people don't ever interact directly with the kernel.

        The entire idea with HURD though is quite a lot different from Linux (and other monolithic designs). The biggest one being that HURD uses user space for almost everything. Ultimately this gives the OS a lot more flexibility and stability.

        On the whole I think that the design behind the HURD is a more interesting than other current OSes. I guess we'll just wait until it's gotten a bit furt
        • On the surface Linux and HURD are very similar. That's because most people don't ever interact directly with the kernel.

          Actually, they are very different, even on the surface, because the surface of the kernel is not the surface of the OS. GNU/Linux and GNU/Hurd on the other hand are very similar. This is exactly why RMS is telling people to call it GNU[/Linux], not Linux. Because it's the OS people see, not the kernel. And the OS is GNU.

          On the whole I think that the design behind the HURD is a mor

      • Do you know if I can run any or even most of my regularly scheduled programming on Hurd? I mean: will Ruby, x.org's X11, GNOME, FireFox, apache, emacs, etc, compile and run as expected?

        As to non-root users can effectively mount filesystems if they have all the permissions needed, how is that different than GNU/Linux, where I can use the /etc/fstab entries for a /dev/* devices or NFS exported filesystem to allow users to mount/unmount to predetermined mount points at will?
        • Do you know if I can run any or even most of my regularly scheduled programming on Hurd? I mean: will Ruby, x.org's X11, GNOME, FireFox, apache, emacs, etc, compile and run as expected?

          Of course, emacs runs fine. As to the other stuff, I believe Ruby is there as well, as is the current XFree86 Debian package from unstable (we have not tried building X.Org yet). Regarding GNOME, it mostly builds fine but there are some runtime issues which need to be sorted out first, it does not startup correctly right now

    • The reason it's called "GNU/Linux" is that it's the GNU system, running on the Linux kernel. The only difference between a GNU/Linux and a GNU/HURD system is the kernel. And, of course, a lot of things won't work on GNU/HURD, because HURD doesn't support them yet.

      My advice? Only try HURD if you're specifically interested in it. If you just want to know what a GNU system is like, look at GNU/Linux. Even one of the BSDs or a commercial Unix will give you a feeling for what GNU is like; after all, GNU's Not U
  • by mbanck ( 230137 ) on Wednesday December 08, 2004 @12:29PM (#11033542)
    Contrary to what I wrote in that post to debian-hurd which got cited for this article, we decided to not do all this patching to have two static ext2fs translators (one supporting big stores larger than 2GB, the default one not) next to each other.

    Instead, after some more testing, we decided to fully apply Ognyan Kulev's patch so that every translated ext2 file system will use it. I committed the code to the Debian Hurd package svn repository yesterday and we will probably upload it by the end of this week.

    Michael

  • by mbanck ( 230137 ) on Wednesday December 08, 2004 @12:40PM (#11033660)
    Michael Bank writes:

    I am called Michael Banck, actually.

    but what else do you expect? =)

    Michael

  • I really want to know! Or does it only exist due to RMS's ego?
  • Linux has its niche of being the first free kernel. GNU folks created the tools to make the kernel, and are trying to make their own.

    Lemee see.. A monolithic free kernel versus a microkernel with darn near everything as userspace ;-) Hell, the only other microkernel worth its salt is Plan9, and it's "NOT FREE".

    Touch the source and the Linux kernel might as well put (TAINTED) by your name.

    Anyways, just cause HURD isnt usable right now doesnt mean it wont mbe in 5 years. Nobody says I have to choose only
    • Lemee see.. A monolithic free kernel versus a microkernel with darn near everything as userspace ;-) Hell, the only other microkernel worth its salt is Plan9, and it's "NOT FREE".

      And Mach. And QNX.
      • And Mach.

        Actually, the GNU Hurd is no kernel. It rather builds upon a microkernel, which happens to be GNU Mach for the time being (work is underway to port it to the L4 microkernel)

        Michael

    • Plan 9 is NOT a microkernel. Also, it's open source. So, unless you're some insane moron who cares more about politics of licenses than technology, you should have no problem using it.
  • The patch is told to be very stable....

    Can someone comment on this as a design methodology? How does this work, exactly? "Listen, patch: you be stable, now. You hear me? Be stable!"

  • Could anybody explain why the previous implementation was limited to 2GB per file system? 2GB sounds like a limitation of the 32 bit address space. With the new 64 bit processors is this still an issue?
    • At least on SGI, and i think on Linux/AMD64, binaries and the kernel can run in 32-bit mode. In some cases, thats might actually be desired.
    • Could anybody explain why the previous implementation was limited to 2GB per file system? 2GB sounds like a limitation of the 32 bit address space.

      Indeed, the old implementation jut mmap()'d the whole file system into memory, resulting in the 2GB limit. This would not be the case on 64-bit architectures; however, I am not aware that GNU Mach runs on AMD64 natively with 64 bits.

      Michael

  • I don't expect this to happen in HURD anytime soon, but what about other OS's? Why don't they support arbitrarily large (>2GB) files? As a video editor, that'd be quite nice.

news: gotcha

Working...