Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Silicon Graphics

XFS Beta 76

Posted by Hemos from the filing-system-fun dept.
Motor writes: "Things have been a bit quiet on the XFS front over the last few months, but a beta is finally here." They've got a document to to read before installing, as well as some installation notes on the site. It looks like it's a patch for 2.4.0-test5 kernel, and you can also get it as RPMs, or ProPack.
This discussion has been archived. No new comments can be posted.

XFS Beta More

XFS Beta

Comments Filter:
  • Are there any comparisons of these too filesystems, i'm especially interested in the speed of those two....

  • Re:Yay!!! (Score:1)

    by Anonymous Coward
    Umm. Reiserfs has been around for some time now. Its robust enough that I've deployed it across all of my servers--including heavily utilized fileservers.

    I'm interested to some extent in XFS because, IIRC, it was optimized for insanely large files (like captured video streams). However, Reiserfs is already here today to serve all your journaling needs.

    Head down to http://www.devlinux.com/projects/reis erf s/ [devlinux.com] and take a look. Its already included by default in the newer SuSE distributions.

  • Offers nothing over ReiserFS (Score:1)

    by Anonymous Coward
    This FS has less to offer then ReiserFS and is a lot more new to Linux.

    If you wan't to play with development FSes, then please give reiserfs on 2.4 a spin.

  • Re:How stable is this? (Score:1)

    by Anonymous Coward
    works fine. have it on a 40gog drive. lets me create huge files, no fsck on boot. I have used it for about 2 weeks now(that patch has been out for about 3)

  • Re:compiler problems but yeah SGI DRT (Score:1)

    by Anonymous Coward
    Any chance of you putting those patches out for us other Alpha people to test/use? Maybe ftp them to ftp.alphalinux.org? thanks.

  • XFS is a type 83 partition?!?! (Score:1)

    by Anonymous Coward
    The XFS FAQ [sgi.com] recommends marking partitions which contain XFS as type 83. This may screw up ext2 aware utilities such as Partition Magic and Ghost as well as possibly making a mess when doing distribution upgrades! What the heck is SGI thinking?!

  • Re:RTFM (Score:1)

    by Anonymous Coward

    Default blocksize on IRIX is 4K.

    Input requested from /. comunity is not provided on TFM:

    Does the Beta linux driver work with very large IRIX created XFS file systems.

    Answer apears to be no.

    Thanks
  • You need to grab the cxx compiler from compaq and recompile POV with it. The increased optimization (expecially against the compaq math libs) might breathe a little life back into your 21164. Info is at: This Page [digital.com]
  • The 2GB limit was (if I recall correctly) due to the Glibc..

    With Redhat 7.0 - this problem is history - so you can use kernel 2.2 and create huge files (I think up to 2 terabytes)
  • Looks like someone doesn't read the news...

    UPDATE: Starting kernel 2.2.18pre9 - there is the NFS V3 - so people should start thinking about migrate from NFS V2 to V3...
  • Hey Thanks!

    In the old days however, Tru64 would only work on Digital Mobos, not on alphaPCs.

    On alphapcs, only NT and linux would work. I wonder if that's still the case.

    ---

  • Okay, so I have this box, a ruffian-21164-600Mhz running debian 2.1 and that's slow as shit running POV (at least as slow as my PII-233)

    BUT! It's a 64bit machine... and what I'm reading about XFS sounds interesting. At least I could turn it into a half decent file server.

    Anybody knows how stable 2.4.0pre is on the alpha? what about XFS? and what about how optimised GCC is become for the 21x64 processors?

    Has compaq got their own journaling fs and a NIX system that works on alphaPC platforms?

    ---

  • Has compaq got their own journaling fs and a NIX system that works on alphaPC platforms?

    I don't know about that specific platform you have but Tru64 UNIX (formerly Digital UNIX I believe) is available and has a journaling filesystem. I'm not sure it'd be affordable for home use though.
  • These limits are still in 2.2 kernels, but there are patches which remove it.

    I know for sure current suse's ship with it, and probably redhat does the same.
  • Cool, a journaling file system... Remove that off of Microsoft's 'Linux Myths'...

    Woah there! Do note that although it's great progress for Linux, XFS for Linux is *still* in Beta. I gather IBM's JFS is coming along too, so the race is on.
    --
  • I've been using ReiserFS as packaged with Mandrake 7.1 whenever and wherever I can, including critical systems. A couple of them litterally mean life or death if they're down, and I've had nothing but success. Were you using an old version?
  • Latest version.. goooood... Some people always have to stay one or two versions back. I know some people who are going to reforge a web server, and they're tossing on Apache 1.3.9. Why? Oh, there might be some bugs in 1.3.12. Yeah, like there aren't any known bugs in 1.3.9. Hint, they're probably FIXED in 1.3.12! Its not like the Apache folks are going to sit around and say, "You know what? This new 1.3.13 version is totally funky, but lets just push it out. We'll then fix the bugs and then offer the patches named with the exact version level as the funky one." WTF?!? If the developer is hinting that everyone should bump up to the latest version, shouldn't their opinion be trusted, especially if the developer isn't getting any kind of reimbursement for you getting the latest versino?
  • If distro's screw up they're broken! Same goes for all the other utilities. True, up until a year or so a go ext2 was the only Linux native FS of importance. That has changed and I'm sure most distro's will do the right thing.

    -adnans
  • I upgraded my laptop to ext3 yesterday. The tools in Debian's "unstable" are ready for it, I didn't check the "potato" distribution. The nice thing about it was that the ext2-to-ext3 upgrade happens in place, and you can back out and mount as ext2 again if you wish. You just install a file in the filesystem as the journal and (this is the one messy part) tell "mount" its inode number. The inode number thing is a consequence of the ext2-to-ext3 upgrade, and should not really be necessary for new ext3 filesystems.

    The laptop now goes through a stop-without-proper-umount and reboot without having to check the filesystems again. I had to change the flags that "lilo" tells the kernel, and had to add flags in /etc/fstab, and had to boot with special flags ("rw") once to create the journal on the root filesystem.

    Bruce

  • ... I perused the XFS for Linux site, but could not find any information regarding LVM or SGI's toolset (revolving around xlv).

    Are they only porting the XFS and none of the LVM support? My memory may be slipping, but I don't recall any mention of LVM (for or against porting to Linux) in any of their online documentation (except for some manpages, which are taken from IRIX)..

    XFS without LVM? Disappointing...

    Your Working Boy,
  • The problem is not the kernel. The problem is the xfs code. It just won't compile with 2.95.2. Breaks with some nice "I have no idea what to do with this" messages.
  • Well, the source will be open, so there's nothing to stop BSD'ers from snarfing the source to port to BSD provided they can get past the licence infection of GPL->BSD. In short, it's probably going to be up to some developers hacking with it.
    --
  • Arse. I used to know that. Damn these version number changes! ;)

  • Compiler version? (Score:3)

    by Psiren ( 6145 ) on Wednesday September 27, 2000 @02:20AM (#751172)
    Due to known problems with later versions of gcc, version 2.91.66 must be used when compiling XFS and the associated kernel.

    Does this mean that gcc 2.9 is officially supported by Linus and co to compile 2.4, or is this just required for XFS?
  • That link is actually a bit old, the ProPack distro for the XFS beta is version 1.4... basically, it's a modified Red Hat installer that "overlays" some nice new features (kernel w/ modifications, kdb, some other stuff) on a supported distribution (red hat, turbolinux, or SuSe, I think...). Makes it _really_ easy to get an XFS box up and running. It does things "automatically" though, so if you like more control over the process, just grab the RPMs or the CVS tree instead.

    ---

  • There is currently no partition type allocated for XFS... any type should work (i.e. mkfs won't complain) but until there's a type allocated, 83 will work. I think reiserfs uses 83 as well...

    And technically, "83" is a "Linux Native" partition, not ext2, so perhaps it's not so bad. :)

    Just keep it in mind when you use a filesystem tool...

    ---

  • Has compaq got their own journaling fs [...]
    You're thinking of AdvFS, which is bundled with Tru64 (formerly Digital Unix). If I remember correctly, it's log-structured (the precursor to modern journaling), supports multiple independent directory trees across multiple volumes internally (i.e. an N-to-M mountable-namespace to physical device mapping), has nice features like snapshotting, and just generally kicks ass.

    I would pay good money to see AdvFS for Linux. I even wrote some code for a work-alike, but got distracted by other things and had to set it aside.

  • I tried it in August, and had a lot of problems.
    I needed XFS support in my Linux box to read a bunch of TGA files from a 18 gigs scsi drive formatted in XFS on a SGI box. Very often my machine crashed and it took me days to get those dawn files. You should wait until the stable version is ready.
  • It's not really a file system issue as much as a VM issue. RAID1/5 does nasty tricks to the buffer cache during resync that breaks the write ordering requirements for journaling file systems.

    Actually, the RAID code has been fixed in 2.2.<late> and 2.4.0pre<mumble>, but I haven't had a chance to look at it yet. I suspect supporting XFS will still take some work. We'll get there.

  • Re:Software RAID? (Score:3)

    by mkp ( 10799 ) on Wednesday September 27, 2000 @05:37AM (#751178) Homepage
    When people mention incompatibilities between journaling and software RAID, they refer to RAID1 and RAID5. RAID0 is trivial block remapping and doesn't suffer from these problems.

    XFS works with RAID0. RAID1/5 is a bit more tricky, but we'll get to it.

  • Re:JFS is nice, but I'm concerned... (Score:4)

    by mkp ( 10799 ) on Wednesday September 27, 2000 @05:32AM (#751179) Homepage
    First of all, XVM (the successor to XLV) is being ported to Linux. It's a prerequisite for CXFS - the clustered version of XFS - and furthermore we want customers to be able to move disk arrays between Linux and IRIX systems.

    You can use XFS on Linux with LVM and MD RAID0. RAID1 and RAID5 might cause problems, because both they and XFS do nasty VM tricks. Since we're determined to go the kiobuf route in terms of I/O, that's were our efforts are concentrated. I'm working on adding kiobuf support to LVM as I type this. MD is next on my list.

    Finally, the man pages have been updated for Linux. They're just not on the web page yet. We weren't supposed to release the beta until Friday, but we accidentally published the beta release web page and it was on Linuxtoday/Slashdot in no time. We're updating the docs as fast as we can. Hang in there.

  • Re:Compiler version? (Score:5)

    by mkp ( 10799 ) on Wednesday September 27, 2000 @02:56AM (#751180) Homepage
    We require egcs 1.1.2 because it's Known To Work(tm).


    We had a lot of issues when using gcc 2.95.2, and we didn't want to fight broken compilers during the beta testing period. Consequently, we've
    set a fairly restrictive set of prerequisites.

  • Re:compiler problems but yeah SGI DRT (Score:5)

    by mkp ( 10799 ) on Wednesday September 27, 2000 @03:11AM (#751181) Homepage
    This is a beta, and we've only done rudimentary performance tuning. Depending on your setup and workload, XFS yields results on par or slightly better than ext2.


    We're working on replacing the current block I/O subsystem in Linux (aimed at 2.5, but will exist in the XFS tree in 2.4). Currently, Linux does block I/O in entities known as buffer_heads, which carry 512 byte payloads. The new scheme is based upon Stephen Tweedie's kiobuf model, and will support big (SCSI supports up to 16 MB/req) I/Os. XFS was primarily designed for big sustained I/Os and once we're done with the kiobuf support we'll start profiling the code and push it to the limits.


    Regarding ports to other architectures: My Alpha here at the office is running XFS, but I haven't committed the changes yet. I ported XFS to it for fun a month ago but never got around to committing the changes. I'll do that at some point. And possibly look at SPARC.


    But then again. This is Open Source. Feel free to hack on it and send us patches!

  • This may or may not be a silly question, but... is there a chance this will be available for FreeBSD in the (somewhat near) future?

    Sorry, I'm not trying to be a troll or anything, I just happen to like FreeBSD a bit better... :-)
  • Note that the ext2 filesystem in FreeBSD 4.0-RELEASE is actually under the GPL, as it uses bits of Linux code; this is why it's disabled by default. I assume it would therefore be entirely possible for someone to produce a port of this to FreeBSD; they just wouldn't be able to ship a compiled version (without saying that the rest of that copy of the kernel was being distributed under the terms of the GPL).

    "I want to use software that doesn't suck." - ESR
    "All software that isn't free sucks." - RMS

  • It looks like they are shooting for 2.4.0 release then. They mention that there is a 2 Terabyte limitation. I think that this is for the entire filesystem not just one ount point, but it is unclear. And yes I have known people to have larger than 2 Terabyte disk space requirements. Right along with there 100 Gig databases. I thought that the Linux kernel got ride of the 4Gig mem limitation. I know there was a 2 Gig and that in 2.2.17 you can select 1 or 2gig max.

    Currently there seems like a lot of limitation on what software you need and all. glibc 2.1.3, kernel 2.4.test-5, etc.

    It is good to see that SGI is still working on this after such a long time of silence. I guess working in the Internet world I kinda expect projects to move at internet time. After all that is what kind of pressures I have to work under. But atlas I am not writing filesystems and drivers.

    I don't want a lot, I just want it all!
    Flame away, I have a hose!

  • first off

    SGI have DRT (Done the Right Thing) so THANK YOU SGI

    XFS is compaterble with the IRIX file system but the implementation is differant in parts

    I wonder how fast this is compared to others, ext2 blew alot of FS out of the water in terms of speed
    anyone got benchmarks of XFS on IRIX and on Linux ?

    Well done for geting the PPC port working but what about ARM/MIPS ?

    I am compileing it on redhat 7 as I type so will try it out

    yes you can compile linux with 2.95.2 but there where problems I would stick to EGCS at the moment and thats what SGI recomend but redhat want 2.96 to work and they are trying to get everything working for the upcoming 3.0

    have fun

    john jones
    (a deltic so please dont moan about spelling but the content)

  • Beta Caveats (Score:3)

    by toofast ( 20646 ) on Wednesday September 27, 2000 @02:08AM (#751186)
    XFS Beta Release Caveats

    Size and Memory Limitations 2 Terabyte filesystem limitation

    Currently XFS is limited to filesystem smaller that 2 terabytes. This is due to limitations in the Linux block device I/O layers.

    The XFS team is working with Linux developers to improve the Linux I/O layers. The improvements will include the support neccesary to exceed 2 Tbyte filesystems.

    4 Gbyte memory limitation

    Well, those "caveats" won't prevent my servers running for a long time!

  • Hrm (Score:2)

    by Levine ( 22596 )
    Just let me know when they'll be beta testing their boxen on my desktop.

    Cheers,
    levine
  • What about ext3 (which provides journalling) - hasn't that been released yet?

    ext3 is available as kernel patches from ftp://ftp.uk.linux.org/pub/linux/sc t/f s/jfs/ [linux.org]; there's still a bunch of issues to be aware of.

    Pro: very nice transition from existing ext2 filesystems and back again. Does journaling so bye-bye long fsck times.

    Con: Does data+metadata journaling so write performance is about 1/2 ext2. Must still be classed as experimental, I wouldn't yet go production with ext3 - reiser seems to be stable enoug to use on production systems right now.

    If you're interested in stuff increasing the availability of your system (journaling filesystems, hardware monitoring, cluster configurations..) the site to visit is http://www.linux-ha.org [linux-ha.org], it's got a nice colection of links to the relevant projects.

  • Don't forget reiserfs [devlinux.com] , which I believe does journalling and is shipped along with some distros (the latest SuSE release , anyway)

  • Anyone tried it out yet?

    I Really wanna try it, but I don't have a box i can run it on where eat the disk(tm) can be tolerated.

    If anybody has any info on how well it works please share..

  • BullSheeee... (Score:3)

    by The Iconoclast ( 24795 ) on Wednesday September 27, 2000 @04:46AM (#751191)
    I like ReiserFS, it's pretty good at what it does, like being a quick and easy journaling FS for your average joe-shmoe desktop power user. I love not having to fsck my 20GB HD on a powerfail. It's really slick that SuSE had ReiserFS in the default install.

    HOWEVER.....

    XFS is totaly designed as a high performance FS. It is fully 64bit (on 64 bit platforms, not a concern on x86), it is growable (very slick), and has basically everything you'd expect from a high-end "commercial-grade" journaling FS. Why? Cause it is. It's the Journaling FS that SGI designed and uses in all of their completely badass servers.

    As for stability, XFS is pretty good now. There are a few issues. I had problems with XFS+Athlon+Ultra/ATA66, but for highend SMP machines with SCSI, XFS can't be beat!

    Also, keep an eye out for IBM's JFS in the future.

  • Tru64 has a hobbyist license for $99.

    Check out http://www.unix.digital.com/noncommercial-unix/ [digital.com]

  • 2.95 is certainly supported for 2.4. As far as I know, 2.96 is not as yet.
  • FreeBSD has softupdates.
  • deltiology n. the collecting and study of postcards. deltiologist n. [Gk deltion dimin. of deltos writing-tablet + -LOGY]

    Hmmm, so a deltic must be one who writes postcards... so his spelling would be bad, because he's not used to being able to write full sentences... a holdover from the telegram days...

    --
  • The 2GB limit is due to limits of the linux VFS (virtual file system) layer. These limits are gone in 2.4 kernels. I doubt that even the recent 2.2 kernels have the capability to go over 2GB, but RH 7.0 might prove me wrong.
  • Personally, I don't really care either. I will never be able to afford that much space (HDD or RAM). And if prices fall to the point where I can afford such things, then I am sure that the kernel team will have solved those problems (considering they will probably own that long before me).

    But, I know of servers (Alphas) that already exceed these limits. How am I supposed to convince these servers owners to switch OSes (not that I'm trying anyway)?

    Devil Ducky
  • Those sort of limitations are actually a problem
    on 64 bit operating systems like an Alpha. For example Wildfire.

    --
    www.alphalinux.org
  • gcc 2.91.66 = egcs-1.1.2

    Per Alan Cox this compiler is OK for kernel.
  • It seems like SGI is a little late in the game... JFS has been available for Linux for quite a while now. I've tried IBM's (which is CASE INSENSITIVE!),
    ext3 (which was pretty good but only available for the 2.2.17pre series of kernels), and finially reiserfs (which 100% totally rocks). I'm hoping that reiser
    will become the defacto standard journaling filesystem for linux and actually be included in the kernel. It's much faster and allows you to do things that you
    couldn't dream of doing with ext2 (i.e., creating 100,000 files in 30 seconds!). It also allows you to choose the hashing algorithm used to store files based on
    your filesystem needs (squid caches, giant files, many small files etc...). My only gripe about all the JFS's for linux is that none of them seem to support
    quotas yet. Anybody know why this is an issue? I'm not saying that it's not great news to have another option available with XFS though. SGI has a superb
    team of engineers, and I'm sure that XFS will be quite useful and dependable when it's done.
  • Will these be stackable block devices??? WE REALLY NEED STACKABLE BLOCK DEVICES!!! ;-)
  • I don't understand why this is an issue. A block device is a block device. What's so different in the handling of RAID that makes it work unlike a direct-to-disk block device?
  • Not to be picky or anything...

    What about NFS exports and ReiserFS on very large disk arrays? We have a raidzone (~500GB Raid 5 Linux box using ReiserFS) in house, and the NFS performance is pitiful (not just because we are limited to NFSv2 exports due to kernel 2.2.16)

    -Jeremy
  • I do read the news. Alot. on company time ;)

    I am aware that NFS v3 will be in kernel 2.2.18

    What about reiserfs and NFS interactions though? I have read that there is some "fighting" going on there...

    Anyone else have performance issues in that combination?
  • My questions aren't meant to be "veiled troll replies"

    I'm just talking from personal experience. I have a system that needs to serve gigabytes of data (very large files). Right now its performance needs to be improved. I'm interested in moving this product to 2.4, after it stablizes. Right now I'm stuck with using kernel 2.2.x Why? This hardware must be stable _and_ usable to my users. Having to wait seconds on a 'ls' on a NFS mounted reiserfs partition on a 500 GB raid is not my idea of a good time.

    I'm all for having a high performance journalling filesystem, and I don't care which one it is. I'd be more than happy to continue using reiserfs, since I believe it to be the most stable fs for this task right now. What I don't like is, again, the poor 2.2.x NFS performance.

    -Jeremy
  • How about using XFS with Linux' software RAID functionality? (At least RAID0 anyway.)

    I keep hearing "kernel people" say that "Journaling Filesystems don't work with Linux' software RAID" but I've been using ReiserFS on a 60GB RAID0 device at home for several months with no problems at all...

    For those of us on a budget (like 90% of us are...) and have to use cheap IDE hardware with software RAID, but want the reliability of a journaled filesystem, this is an important question!

    -=-=-=-=-

  • XFS is totaly designed as a high performance FS. SGI has a history of being speed-demons. I remember in the mid '80s when they decided to go to X-Windows, someone mentioned that the release was delayed because SGI engineers concluded that the X implementation was too slow and they had to rewrite parts of it to get it up to snuff. I presume that they would do the same thing with a File System generated rom scratch.
  • In other words, you can move your 500GB HARDWARE raid array from your O2 to an intel box, as long as it's created with 4K blocks. This could easily be untrue -- especially for filesystems tuned for large files, where larger block sizes woud make sense. -- So make a backup before you try this at home (You have the O2 at home?)

    (Shame about that 2 Terabyte size limit, though. I guess I'm gonna have to go buy myself a couple dozen extra hard disks. (that and a RAID controller). :-)

  • probably not. i doubt that fbsd kernel team wants to include gpl'ed stuff into the fbsd kernel.
  • anyone who wants to explain what "propack" is?.
    i looked at xfs web page and couldnt find any info on it.

  • journaling FS (Score:5)

    by emir ( 111909 ) on Wednesday September 27, 2000 @03:00AM (#751211)
    i dont know if anyone is interessted in this but there is a great article on journaling filesystems [linuxgazette.com] at linux gazette [linuxgazette.com].

    it explains different features and concepts related to the 4 different journaling filesystems. XFS, JFS, Ext3 and ReiserFS.
  • True but at my company, our experiences with Reiser FS were NOT good.. I believe we had it installed on our of our Arena boxes (100GB) and it ate the file system.. Not good...
  • Cool, a journaling file system... Remove that off of Microsoft's 'Linux Myths'...
    Now if we could only communicate Linux's amazing uptime without being anecdotal.
  • I hope I'm not offending you in anyway, but what's a 'deltic'? Just curious.
  • Here is the page you wanted [sgi.com]. You have to put up with 'scalable, reliable blah di blah di blah' (is that bumf a legal requirement for computer companies now?) on the first page, but there's quite a bit of useful info on it. I think I might give it a go when I've got a bit of spare time.

  • from the FAQ [sgi.com]:

    Q: Can I run XFS on top of LVM?
    Yes you can but you need to use a patch for LVM because the XFS kernel contains stephen tweedies sard patches which change the format of /proc/partitions. Also for using XFS on LVM you should not enable the kiobuf option in the kernel XFS compile options. You may get a patch (created by William L Jones) to start from at

    http://innominate.org/~graichen/projects/xfs/lvm .patch

    See the head of it for details and a list of contributors.

  • RTFM (Score:2)

    by [JP] ( 152370 )
    Haven't you read the article?

    • 4k filesystem block size limitation

      For the current release of XFS, the filesystem block size is limited to the size of a memory page. On a x86 architecture that size is 4 Kbytes.

      Note that files systems created on an IRIX/MIPS platform must have been created with a 4 Kbyte block size in order to be mounted on a ia32 Linux system. File systems not created with a 4k block will fail to mount with an error indicating the mis-match.

  • You might not need a 2TByte file system, but there are industries where data is getting up into the realm of the PetaByte.

  • " I remember when Sun really was about open computing" If there ever is a war between SGI and SUN (they are across the steet from eachother in MT View) I am going to go root for the SGI team :)
  • Well.. This is a beta release however, I attended one of those sgi linux university road tours and I watched a presentation on XFS as it exists for IRIX systems. The specs are truly amazing. Right now ReiserFS might be the way to go but tomorrow XFS will rule. XFS is SGI's crown jewels and they are GPLing it! This means high availability for linux. Databases running on linux using XFS will be the king of the crop.

    The performance of most UNIX filesystems significantly degrades as the number of entries per directory grows - Not with XFS. You could have a directory with thousands of entries and due to the B-trees table structure the lookup and response time is not much different if you only had a few entries.

    On IRIX XFS is capable of handling files as large as a million terabytes. XFS is a 64bit file system and offers near raw i/o performance. XFS will bring linux the filesystem stability it needs to be considered an enterprise OS. While IRIX can boast these numbers it will be a little while before linux can. On the other hand, I am happy with ReiserFS on my home desktop. There are people who use ReiserFS on their servers. The enterprise will be very happy with XFS on Linux.
  • Yeah, mandrake had it for an option. I would have loved to use it but the bootmanager I use [xosl.org] didn't recognise it.
  • Does anyone know if this will allow files of greater than 2GB in size? According to Stephen Tweedie, ext2 is limited to 2GB due to limits in the kernel. Are these limits lifted in 2.4 or are we going to still be stuck with a 2GB maximum file size for the forseeable future?

    HH
  • There is no such thing as gcc-2.9

    Besides, compiler requirements are different for different architectures. While it's not a good idea to use anything older than gcc-2.95.2 for most platforms, users of i386 tend to be more comservative because some i386 code was written when gcc-2.95 didn't exist at all, so that validity of some assumption is yet to be tested. I'm using gcc-2.95.2 on all platforms, but stability is not a big concern for me.

  • Should have been a goatse.cx link, I'm really getting dissapointed in these trolls.

Slashdot Top Deals

If I want your opinion, I'll ask you to fill out the necessary form.

Close