Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Linux Software

UK Linux Conf 91

PaulJS writes "The UKUUG are holding a Linux Conference on 25th - 26th June 1999. Topics include GNOME (design decisions) and the ext3 filesystem which is a contender for the replacement for ext2. "
This discussion has been archived. No new comments can be posted.

UK Linux Conf

Comments Filter:
  • It is not true that all journaling file systems save *EVERY* change to a file for all time. They usually only keep a log of outstanding transactions up to the point that the transaction is committed to disk. Their primary purpose is to provide rollback recovery of incomplete transactions in the event of a system crash thus avoiding corrupted disks. Anyone not wanting to recover a file system after a crash (e.g. most anyone with a computer turned on 24x7x365) will want to run one.

    The class of file systems you're describing are best represented by ClearCase versioning file system, a meta filesystem which does save all changes for all time (as well as a ton of other things). BTW, ClearCase is an expensive product from PureAtria requiring big, beefy resources to run well.
  • This has been covered on the linux kernel mailing list, and is in the FAQ here [tux.org] The gist of it is, ext2 is fast enough on half-decent hardware
  • I thought it was in Manchester last year?

    But yes - cheap beer is good. Free accomodation, because She Who Must Be Obeyed is currently at Uni in Bham, is also good :)

  • No, that's versioning file systems.

    *sigh*

  • Converting all the sh-utils, binutils, textutils, all file managers, etc, to take this meta-data into account is a non-trivial task.

    That's why it's not been done.

  • I think you can safely assume that the holes will be filled in with big names.

    p.s. the name of the nation is "United Kingdom", not England. Alan Cox lives in Wales, a different component of the UK to England.

  • Either it is or they rewrote it in the manner described. Certainly if you used the "cp" out of the GNU shell-utils, it would be broken, yes.
  • I think the problem is, people have gotten into bad habits. Some programs put very big files into /tmp, when they should probably use /var/tmp. And certainly on my system, elvis drops it's recovery files into /tmp when it dies (though this presumably is a compile time option).. Anyway, /tmp on ext2 is generally fast enough - there was a discussion on linux-kernel about this recently, IIRC.
  • NTFS, anyone? *ducks*
  • Posted by Martin Houston:

    Unfortunatley room hire and other things like that in the physical world are not copyable and moveable for pennies (the norm for the net).

    If you are invited to a large scale, well organised and FREE event you would have to wonder what the hidden agenda might be - the 'Message from our Sponsors'.

    The UKUUG event is priced so that it covers its costs and be beholden to no-one for behind the scenes financial support.

    Open Source software means that you do not have to put your hand in your pocket nearly as often. It cannot eliminate it completley.

    If enough people support such events then there will be more of them and at lower costs.

    Showing our faces at such things is also a great way to give the Open Source movement a public face. Richard Stallman's talk at the Commonwealth Institute a couple of months back even made it onto National radio in the UK. - that was a sitting in the isles capacity crowd.
  • Posted by David Hallowell:

    The booking deadline is now on the website

    --
  • Posted by David Hallowell:

    The official booking deadline for this event is Friday 18th June - that's a week before the event starts. I mention this becasue it the time of writing this isn't mentioned on the website, however I'll make sure that is sorted out in the near future.
    Of course it's best to book as soon as possible to ensure you can get a place at the evemt.

    Regards,
    David Hallowell
    UKUUG Council Member

    --
  • not only do programs dump large things in /tmp but half the stuff in there is just named pipes....which don't even matter when it comes to fs performance.....
  • Eh? What do you even mean? You dont have to open the file now to get at attributes. Type "man 2 stat". That's how it's done.
  • I remember similar things being discussed on linux-kernel in other lights, and there are many people who would never let this happen :). Most peoples' idea was to have a separate directory for these attributes, and keep filenames the same.
  • can't count how many times I've had to just power off the system

    Doesn't sound too good. Are you developing driver software?

    Now that we have the most stable OS in the world

    Do we? How do you know?

  • by Erik Corry ( 2020 ) on Sunday May 23, 1999 @07:57AM (#1882517)
    XFS is a lot more than "just" a journaling FS. One of it's other major components is guaranteed I/O rate partitions

    Yes but they are not giving away the guaranteed I/O rate part of it. At least not according to this link [slashdot.org] though I can't find any mention of that in the news story [news.com] or the SGI press release [sgi.com].

    I haven't seen what EXT3 promises,

    It will add journalling (see the white paper [linux.org] Stephen wrote), and probably extent based block lists and btrees by Ted Ts'o [deja.com] will be in there too.

    Linux does need a journaling FS and XFS may be the best bet, but it won't happen quickly unless SGI puts some serious resources behind it.

    SGI are employing kernel hackers [slashdot.org] and you can start to see some of the stuff they are getting up to [geo.uu.nl]

    Also, just who has the resources to test large production systems (4+ CPUs) on an OS under test? Corporates, that's who. And they'll contribute their code to Open Source, right? Because...?

    Hell, we've got MS helping us by looking for performance bottlenecks for us [slashdot.org] and that is already starting to bear fruit [slashdot.org] (I can't seem to link to that article right. Check out the article "Re:Thank you Microsoft!" by petchema. You will need Alt-F to find it.)

    Personally, I think ext3 will rock. This isn't Stephen's first file system by a long chalk.

    may have a price current purists will not like but will have to accept (ie less than Open Source code licenses

    We can't succeed by destroying ourselves, and I don't think the Linux community will try. If XFS weren't Open Source [opensource.org] then it would fail to gain any market share against ext3. But it will be Open Source, so it's a moot point.

  • Perhaps Linux should have one secure filesystem with journaling, software raid/mirror possiblity and so on.

    I want a feature...

    I used to have a few VMS accounts on a VAX and a nice feature was when a file was updated, a new file with an incremented revision suffix was made. Example:

    test.c
    test.c.1
    test.c.2 ...and so on.

    This made it nice when making revisions to a source file and along the way I made some grave errors. Going back and finding a version was an easy process as the filesystem did the same to the binaries. If this was annoying and took up disk space, the incremental file flag could be turned off for directories or files.

    There were many other dodads in the VMS filesystem, like ACL's and all that. Most I didn't use, but it was nice that they were there.

    Are things like these an option for me with my Linux box?
  • by Michael Snoswell ( 3461 ) on Sunday May 23, 1999 @05:17AM (#1882519) Journal
    XFS is a lot more than "just" a journaling FS. One of it's other major components is guaranteed I/O rate partitions. When you create these special partitions, the OS tests the disk I/O rate then lets you specify up to the tested rate and then the OS will guarantee you the I/O rate you selected (can be less than the max), nomatter what the machine is doing (ie even under really heavy load, network, UI etc).

    This sort of thing is needed when doing uncompressed cinema res images at 24fps (or HDTV) where you need 90-130Mbyte a sec from the disk nomatter what else is going on.

    There's a cable channel using 24 odd uncompressed TV res video streams for live delay rebroadcasting (across time zones) using XFS. Works nicely.

    Linux doesn't need this right now. Why? Because it's kinda obvious that the whole OS needs to be in on this act, it's not just a FS thing. True, the guaranteed rate stuff can be treated discretely (ie left out). But I think people may be naive when they say, "Yay, use XFS."

    I haven't seen what EXT3 promises, but I bet that the current implementation of XFS has fingers going *deep* into IRIX that won't make it a fast retro fit into Linux, compared to EXT3 (unless EXT3 is just conjecture at this time, or only a modest improvement. This'll be why Linus wants a full rewrite: to get greatly improved performance will need a lot of changes on the OS side, and if you're going to go to that effort, you'd better make it worthwhile)

    Linux does need a journaling FS and XFS may be the best bet, but it won't happen quickly unless SGI puts some serious resources behind it. For any other effort to pool together enough ppl for long enough to make it happen is just too unlikely for us to just sit around hoping for.

    Also, just who has the resources to test large production systems (4+ CPUs) on an OS under test? Corporates, that's who. And they'll contribute their code to Open Source, right? Because...?

    This *will* all happen, but I think some of these tougher OS issues will need corporate backing that may have a price current purists will not like but will have to accept (ie less than Open Source code licenses or maybe even (cringe!) binary drivers).

    My 2 cents worth.
  • You're right the UKUUG Linux conference was held in Manchester last year, what the poster was probably talking about is the other (non-UKUUG) Linux events which have been held this year.
    --
  • The answer to your question is, yes they will be selling stuff at the conference.
    --
  • XFS is a lot more than "just" a journaling FS.

    Indeed, it's something like 180K lines of code. It has tons of things that are sometimes extreamly useful. Not just the guaranteed I/O rate stuff, but b-tree baised directory lookups (no more slow operations on bloated news directories). Adding more disks to an existing XFS filesystem is great. It's all great.

    At a price. It's 180K lines of code after all! I don't see a 8M second hand 386SX running XFS. I think there is a future for EXTn. If EXT3 comes soon enough, it could have a long future. If it comes too late I'm not sure who will want to hack on it rather then XFS.

    Linux does need a journaling FS and XFS may be the best bet, but it won't happen quickly unless SGI puts some serious resources behind it.

    What does SGI have to do "quickly" other then actually release the code? You mean just because it's big Linux hackers can't get it to work on their own? Only "real" SGI programmers can do anything with it? If so SGI isn't getting much by giving it away! What happened to "with enough eyes all bugs are shallow"?

    Also, just who has the resources to test large production systems (4+ CPUs) on an OS under test? Corporates, that's who. And they'll contribute their code to Open Source, right? Because...?

    Well tons of 2CPU tests will be done becasue 2CPU machines are cheep enough to be affordable to hobbiests. The K7 may or may not make 4+CPU machines affordable as well. "Corporates" may well put some time into testing "Linux XFS" on big machines because they think it is a useable platform. Or they may not. It's not like they owe Linux anything. The bigger distribution componies (i.e. Red Hat) may well do testing, or donate test equiptment, they make their living off Linux after all, and many of them are gunning for the server market.

    But does it matter if it gets 4+CPU testing? If Linux isn't commonally run on 4CPU systems then it won't see much 4CPU test, nor will it be easy to argue 4+CPU is important to it at that time. When 4+CPU becomes important it will see lots of testing there.

    This *will* all happen, but I think some of these tougher OS issues will need corporate backing that may have a price current purists will not like but will have to accept (ie less than Open Source code licenses or maybe even (cringe!) binary drivers).

    Linux only has to pay that price is it views corprate acceptance is a goal worthy of that price. If it holds it's ground either corprate acceptance will come anyway (that appears to be happening at the moment), or it won't, but Linux will still be "pure".

    So before you accept a binary licence, or a single bit of software that is less open then you want, ask yourself how bad do you really want it? Is there another card you could buy that's maybe only a little slower (or more expensiave) that has a more open driver? Or is it something you can do without for a while?

    You only have to give up what you are willing to give up.


    P.S. this doens't mean you have to give nothing up. I have a copy of Civ call to power, and no source code. It's a deal I was willing to make. But I don't have a single card in my machine I don't have driver source for, even if that means I don't get anything like a SB Live for 18 months (my best guess on how long an open alternitave takes to arrive). Other people are free to make other choices.

  • Solaris /tmp is shared between disk and ram. It does that so things that would be in ram are moved to disk if they arent used very often so that you dont waste memory.... It uses all available memory as cache...(im sure linux does too)
  • I wonder if there will be a divide between those who want EXT3 to become the new standard or XFS (assuming it becomes a decent open-source alternative)...
    I personally think XFS is great and hopefully SGI will release it under a pretty liberal license.
  • I wonder if there will be a divide between those who want EXT3 to become the new standard or XFS (assuming it becomes a decent open-source alternative

    The more the merrier. Except when it comes to pretty low-level disk manipulation, the choice of FS isn't going to hinder application compatibility, and all the major distros (if smart) will provide all the free FSs.

    Now, if SGI releases XFS under the GPL, will a hacker port the XFS VFS to a OS/2 XFS IFS? It's already been done with ext2...
  • by fishbowl ( 7759 ) on Sunday May 23, 1999 @07:02AM (#1882526)
    You misunderstand what JFS is all about.
    JFS does not function as revision control.
    It's not keeping a rollback buffer of the
    contents of your files, just the status of
    the filesystem.

    It's all about filesystem integrity.

    To quote Chris Tyler on the topic:


    "A journalled file system writes all of the proposed changes to control structures (superblock directories, inodes) into a journalling area before making those writes to the actual filesystem, then
    removes them from the journal after they have been committed to disk. Thus if the system goes
    down, you can get the disk into a sane state by replaying/executing the intention journal instead of
    checking every structure; thus an fsck can take seconds instead of minutes (or hours).

    For example, if you're going to unlink the last link to a file (aka delete the file), that involves an
    update to the directory, inode, and free list. If you're on a non-journalled system and update the
    directory only, you have a file with no link (see /lost+found); if you update the directory and inode
    only, you have blocks missing from your free list. Both of these require scanning the whole disk in
    order to fix; but a journalled system would just update the directory, inode, and free list from the
    journal and then it would be sane.

    Problems with journalled filesystems include conflicts with caching systems (e.g., DPT controllers,
    RAID subsystems with cache) where the intention journal is not committed to physical disk before
    the writes to the filesystem commence."
  • by prok ( 8502 )
    I can't seem to find the bug in the bug database right now, but there was a bug filed against cp on BeOS for not copying attributes. The DTS response was that since cp is an old shell program, making all sorts of wacky BeOS specific changes was undesireable. (or something like that :) They also pointed out the BeOS specific utils like copyattr, rmattr, et al.
  • Yeah, even though it's a not-for-profit
    venture, it's kinda prohibitive for students
    and the like :(
    I think it's really the slice that the venue
    takes which hikes the price up.

    Maybe the next conference should take place in
    a field somewhere? :p
  • None of these tools would have to change, just the filesystem driver. All those packages you named compile using out of the box using cygnus on NT on an NTFS filesystem after all.
  • Are you saying that cp on BeOS is broken then?
  • This is called "metadata", and is absolutely critical for any modern filesystem to implement. The more OO your environment becomes, where you're looking at devices and resources and sockets and so on through the filesystem, the more you need to be able to attach arbitrary property sheet handlers. NTFS does this extremely well.

    Unfortunately there are "file mode forever" people on linux-kernel who would rather keep linux a clone of a 70's OS than add anything people might actually use.
  • >Also, just who has the resources to test large
    >production systems (4+ CPUs) on an OS
    >under test? Corporates, that's who. And they'll >contribute their code to Open Source,
    > right? Because...?

    What about hardware manufacturers they routinely
    test and assemble systems and can afford to try
    running new OSes on them.. the benefit to them is
    being able to offer their customers a better
    system
  • You are wrong. You can write your own driver in a clean room fasion (if you haven't seen the source code). You can't base a driver on the source code though unless the license that the code is under allows this.
  • Oh, yah that's entirely legal. Sorry, I thought you meant check out the source code to XFS.
  • I don't see how cp could possibly preserve meta-data. There is no copy() system call. All cp does is open the original then create a new file, read that data from the original and write it to the new file. Meta-data would certainly be lost in this situation. mv could preserve the meta-data w/o modification since it makes a system call to do all of the work. Things like tar definately would need to be changed. The changes would only take a few minutes, but then multiply that by 1000s of apps. Also, you lose some compatability with other OSes. Now while I think meta-data isn't an entirely bad idea, I think there are other ways of implimenting it that would require less work, and possibly could be more extendable in the future. Ie, having a separate directory something like .meta/ that would contain all of the meta data. Sure you would still have to modify cp and some utils to preserve the meta data, but things like tar would require no modification.
  • by dirty ( 13560 )
    I think that ext[23] will remain popular because for many ext2 is the linux fs. Sure XFS might be great for some. But I imagine most people will just stick w/ ext2. Also, converting from ext2 to xfs would most likely be a very difficult task.
  • by jerodd ( 13818 )
    SGI recently announced they were donating their XFS, which is a journalled filesystem, to Linux. I don't know if they will really donate it (i.e. release the code under the GPL), but we'll see. If they do, it will be a great gain for the GNU/Linux community, although it would somewhat deprecate Tweedie's work.

    I haven't been able to find more information on SGI's donation of XFS. Anyone have some links?

    Cheers,
    Joshua.

  • Will I be able to "od ." and get a directory dump on an ext3 filesystem like I can on a 'proper' Unix system?

    No, because a proper Posix system doesn't define what opening a directory as a stream should do (IIRC, it does define an error code for such an action). Thus, attempting to read a directory as a file results in undefined behavior--on older Linux kernels, you got the raw directory; on Seventh Edition UNIX, you got data blocks which the C library's opendir(3) functions and friends actually used; on Windows, OS/2, DOS, or newer Linux kernels, you get an error.

    The proper way to read a directory is the system calls to open and search a directory.

    Cheers,
    Joshua.

  • This very thing, copying files that have metadata associated with them, is what makes metadata a nightmare. On OS/2, we called these extended attributes, and taking care of the EAs was always a pain. OS/2 has a DosCopy system call which properly copies the extended attributes over, but what if you're processing data as standard input or output? Extended attributes were useful for some things such as associating an icon with a file or storing compiled bytecodes for a program, but handling the out-of-band data was never, ever, fun.

    We really need an object-oriented filesystem if we want concepts like these. To get that, we also need an object-oriented language (Java is a good choice, C++ doesn't count due to lack of things like decent memory management) and on object-oriented kernel (Hurd might fit the bill some day).

    Cheers,
    Joshua.

  • ya mean 24x7x52 ?

    ;-)
  • Why not let a file consist of severa "fields", every field content defining the meaning of the next field. Let's say the first field is the name, and the second field the type of the file (Yeh, and we are not in UNIX anymore?), and that type determines the meaning of the next field (For text/plain, that would be a description field and the fourth the content), i.e. the number of fields and their meaning is not defined by the FS, but by the applications using the file? OK, I dont't think this will ever be added to a FS for Linux, but hey, I want to dream too...
  • Hm... I'm no lawyer, but from what I know, you can not copyright the FS, just the driver source? So if it is released under an OSL, but not GPL, we just read out how the FS works, and write our own driver? Or am I wrong?
  • I did not mean "look at the source and write something similar", I meant "look at the source what the datat format is and write a totally new driver for that format". Don't know if this is what you mean by "base a driver on the source code"...
  • I noticed that BeOS can add attributes to files that are part of the filesystem. i.e. You don't need to open the file to get at those attributes.

    Wouldn't something like this be useful for ext3?

    AFAIK, it would speed up searches for files...

    Does XFS do this?
  • I meant that BeOS can set User Defined attributes like "author", "project" or "department"

    You can then search on those attributes and Those are v fast.

    Hope this clears things up.
  • I'm not sure if FS merrits is off topic, but since it was mentioned in the article... Journaled FS' are great. There is slightly more overhead involved there, but the stability offered is wonderfull. I work with AIX at work & can't count how many times I've had to just power off the system and it comes right back up. Journaling also provides *some* (though little) level of abstraction, allowing for more deviation from the standard partition scheme. One of the things I've wanted to see in Linux is the Logical Volume Manager from IBM, or something like Verritas, or HP's Volume Manager. If we could build that into the kernel, it seems to me that these would be the "features" that everyone wants to see. Now that we have the most stable OS in the world, I hope we can provide all the features that make the *commercial* OS' so consumable.
  • At last a UK Linux conference I can actually afford to attend. The recent Netproject and UNICOM Linux and open source conferences cost around £300 (excluding VAT) to attend and when you add the travelling expenses to that they were really unaffordable and these events were only for one day.
    However this one is really excellent value for money as this one only costs £70.50 inc VAT (+ £20.57 for UKUUG membership if you're not a member).

    Now all I have to do is check that I can get time off work and if I can I'll be there.
  • I wasn't aware of NTFS doing this, but is it really possible to do useful (read non-trivial) things with OS-maintained metadata? I'm concerned about semantic differences between
    • cp filea fileb
    • mv filea fileb
    • cat filea >fileb
    • cat filea filec >fileb
    • cat filea >>fileb

    Given the prevalence of shell scripts in Unix systems, sloppy semantics could easily lead to a debugging nightmare ...

  • by rullskidor ( 27874 ) on Sunday May 23, 1999 @01:04AM (#1882549)
    It all depends of it[xfs] is GPL or can become gpl, if not I can't imagine it would ever stand a chanse of becoming standard. It would be to bad to have the standard file system under a conflcting lisence and be forced to use a module....
  • I so excited to see, that there was going to be an
    event here in England, giving me a bit more chance
    to meet and hear more Linux people.

    Unfortunately, the thing seems to be a bit "steep":
    a pass is £78 for the 2 days and nearly £60 if
    only attending on the Saturday. Plus you have to
    be a member of Uk's unix group... I shall have to wait for
    something a bit more Open.
  • It should be a good event. As the previous poster said the vacnat positions will still be filled although the speakers for these vacant slots mustn't have confirmed yet. As with all conferences there will be backup speakers in case the ones planned cannot make the event.
    UKUUG events have been knowing to be expanded beyond their scheduled time - UK LISA 98 was extended to four days (it was originally meant to be a two day event). I'm not saying that the Linux conference will be extended but their track record suggests that they'll have no problems filling the vacant slots.

    The most important thing about the conference, however, is the opportunity to meet other Linux users from around the UK as well as the panel sessions where you have a chance to put your questions to a panel of speakers. Hopefully the panel will be able to address all the questions put here about ext3 as well as anything else you want to talk about.


    --

  • > If enough people support such events then there will be more of them and at lower costs.

    That is true. If this years event is big I'm sure something MASSIVE will be organised in the UK and as more people will attend the cost per person can be reduced.

    --

  • Perhaps Linux should have one secure filesystem with journaling, software raid/mirror possiblity and so on. And one extreamly fast filesystem

    How about XFS = Secure FS and ext3 = Fast FS? I don't think (for my purposes) that i need a journaling FS, I'm doing pretty good without it, so i could use ext3, while anyone who needed the extra security could still have it.
  • Nicholas Petreley interviewed the SGI folks. It's at:

    http://www.linuxworld.com/linuxworld/lw-1999-05/ lw-05-sgi.html
  • Put your source in CVS.

    Cyclic Software [cyclic.com]

  • I think that we definitely need a journaling FS- this is one of the things *that* benchmark highlighted.
    As it stands XFS would be a complete FS that presumeably could be included in the kernel with minimal fuss. Compare this with ext3 that would either be extended ext2 or as Linus seems to want, an entirely new FS built from scratch.
    Certainly XFS would be something that would lend credibility to "enterprise" Linux.

    Skill
  • I see your point, but, couldn't the bare bones of XFS, i.e "The bits that work"... Be the starting point of a scratch built ext3.
  • It's a bit off-topic, but:

    Switch is a system that works like a credit card, but the money comes out of your current account immediately. It's very popular since all the transactions show on your normal bank statements and you aren't faced with horrible bills at the end of the month.

A physicist is an atom's way of knowing about atoms. -- George Wald

Working...