OpenBSD Journal

Upcoming Filesystem Mini Hackathon Needs Hardware

Contributed by dwc on from the 'ware-the-inodes-of-April dept.

Nikolay Sturm has put out the call for hardware loans (or donations!) for the next OpenBSD Mini Hackathon, focused on Filesystems, taking place in April in Vienna.

Needed Hardware:

  • Several fast build machines with at least two harddisks, amd64 preferred
  • At least one machine with more than 4GB of memory, amd64 preferred
  • Hardware to build a raid with 2 or more TB
  • USB sticks and the like with misbehaving MSDOS filesystems
  • Lots of harddisks

If you are willing to provide any of the above mentioned hardware, please contact Nikolay Sturm (sturm@).

(Comments are closed)

Comments

  1. By Renaud Allard (85.201.63.39) on

    It would maybe be a good idea to make the title a little bit more precise. In which ways will the filesystems be upgraded?
    I think the most interesting filesystem thing that's missing on OpenBSD is a clustered filesystem (like gfs but reliable) or even better a replicated filesystem (like peerfs but not afs which requires kerberos). I am really willing to help monetarily if one of them is going to be present on a stock OpenBSD install especially for the replicated one.

    Comments

    1. By Anonymous Coward (130.235.35.150) on

      > It would maybe be a good idea to make the title a little bit more precise. In which ways will the filesystems be upgraded?
      > I think the most interesting filesystem thing that's missing on OpenBSD is a clustered filesystem (like gfs but reliable) or even better a replicated filesystem (like peerfs but not afs which requires kerberos). I am really willing to help monetarily if one of them is going to be present on a stock OpenBSD install especially for the replicated one.

      That's the first thing comin to my mind every time i find myself waiting for some fsck after a panic. And thats exactly what i think every time my friends are makeing fun of me because i can't have large partitions.

    2. By Marc Espie (espie) on

      > It would maybe be a good idea to make the title a little bit more precise. In which ways will the filesystems be upgraded?

      Read the specs of the wanted hardware. Even though I do not do
      any hacking on the filesystem, I think this is fairly obvious.

      Systems with lots of memory, and enough disk to build a large disk array. We're talking size issues, the kind that you tend to run into with amd64 systems these days. UFS2, anyone ?

      Apart from that, you can't expect hackathons to actually `run' into any direction. Stuff just happens, and you get new features. It's really impossible to predict stuff in advance.

      The development might be influenced by the hardware you provide. If you really want big amd64 systems to work with >4GB of memory, then lend some ! this will inspire some developers...

      (and if you send some beer, I'm sure some of my fellow developers will appreciate it. ;-) )

      Comments

      1. By David Gwynne (dlg) on

        > Systems with lots of memory, and enough disk to build a large disk array. We're talking size issues, the kind that you tend to run into with amd64 systems these days. UFS2, anyone ?

        this is very important. there are a few issues that need to be solved to be able use large block devices and therefore filesystems on them, and this hackathon is the perfect time to address them.

        if you guys want an idea of specific hardware to try to hook these guys up with i would recommend you try to get them this:

        - a Dell PERC5/E (supported by mfi(4)) and an MD1000 enclosure filled with 500GB SATA disks.

        Of course, a machine to plug it into would be nice as well. A Dell 2850 is perfect for the job.

        - an 8 port or more Areca RAID controller (supported by arc(4))

        It's very easy to get large volumes onto these controllers because SATA is so cheap. They also have the added bonus of being able to do block sizes of 4096 bytes, which is useful for working on how our filesystems cope with that difference to the normal 512 byte block size.

      2. By Anonymous Coward (74.115.21.120) on

        > If you really want big amd64 systems to work with >4GB of memory, then lend some ! this will inspire some developers...

        That already happened. Twice. If that HP machine didn't inspire then nothing is going to.

    3. By pedro (82.135.31.244) on

      this is not how hackathons work

  2. By Anonymous Coward (63.237.125.20) on

    I've a USB stick I tried to fdisk/disklabel/newfs_msdos, mount, copy files, umount.
    Then plug into a MS box, and it comes up as drive is not formatted...

    Format with MS, copy files, mount on OpenBSD, no problem.
    Drove me batty one afternoon...

    Is this the kind of thing you're looking for?
    What address shall I send it to?

    Comments

    1. By David Gwynne (dlg) on

      When you attach the device it should come up with something like this:

      umass0 at uhub2 port 6 configuration 1 interface 0
      umass0: SanDisk Corporation Cruzer Micro, rev 2.00/0.20, addr 2
      umass0: using SCSI over Bulk-Only
      scsibus1 at umass0: 2 targets
      sd0 at scsibus1 targ 1 lun 0: <SanDisk, Cruzer Micro, 0.2> SCSI2 0/direct removable
      sd0: 488MB, 488 cyl, 64 head, 32 sec, 512 bytes/sec, 1000944 sec total

      on the second sd0 line it tells you how many bytes per sector it has. if it isn't 512, then its a funky device that these guys are interested in.

      i think your problem is something else though. windows doesn't understand bsd disklabels, so you have to only use fdisk to set up the flash disk for use between operating systems. however, this means that you wont be able to plug your flash disk into an openbsd box that doesnt use an mbr (eg sparc64).

      my solution is to newfs the c slice (eg /dev/rsd0c) and use that for my msdos filesystems. that seems to work fine on any box ive plugged it into, with any operating system.

  3. By jr (131.130.1.143) on

    Wow, a hackathon in my home city? very nice.

    admittedly I cannot provide any hardware but would you appreciate a pallet of viennese beer as well? :)

    Comments

    1. By pedro (82.135.31.244) on

      sure

    2. By infoomatic (193.170.51.2) on

      > Wow, a hackathon in my home city? very nice.
      >
      > admittedly I cannot provide any hardware but would you appreciate a pallet of viennese beer as well? :)


      I'm also looking forward to this in vienna ;-)
      I might be able to loan my workstation I will buy soon (but this won't be an amd), hope to earn enough money besides my studies ;-)

  4. By Sacha Ligthert (85.146.77.172) sacha@ligthert.net on http://ligthert.net/

    I have a amd64 (2Ghz/1.25GBram) doing nothing at the moment. I could lend it to you for this Hackathon (stripping it harddisks and soundcard). But the transport from Amsterdam to Vienna could be troublesome. Suggestions?

    Comments

    1. By pedro (151.136.100.2) on

      please get in touch with sturm, and we can sort this out

      Comments

      1. By Sacha Ligthert (85.146.77.172) sacha@ligthert.net on http://www.ligthert.net/

        > please get in touch with sturm, and we can sort this out

        No go, currently I am having a huge fight with my girlfriend at the moment (serious bitching while I am typing this) due to some promise I've made in the past. Sorry :-( I wish I could help.

  5. By Anonymous Coward (208.252.48.163) on

    Anyone interested in diving into ZFS?

    Comments

    1. By nomercy (63.148.127.226) on

      > Anyone interested in diving into ZFS?

      I've begun work on ZFS though I'm not a dev. Work has been slow because I have no time. So far I have one of the debug tools building on i386 but there is a ways to go. Hopefully I'll have something more to send over to them by the time they start hacking.

      Comments

      1. By vmalloc (67.52.252.178) kyledrake@gmail.com on

        > > Anyone interested in diving into ZFS?
        >
        > I've begun work on ZFS though I'm not a dev. Work has been slow because I have no time. So far I have one of the debug tools building on i386 but there is a ways to go. Hopefully I'll have something more to send over to them by the time they start hacking.

        I'd be interested in joining this. I'm wondering if it's better to wait for the FreeBSD port to come out though, as it would probably be quite a bit easier to port from FreeBSD than from Solaris.

        Comments

        1. By pedro (151.136.100.2) on

          becareful with the license

          Comments

          1. By Nate (Nate) on

            > becareful with the license

            Indeed, though FreeBSD doesn't mind CDDL and APSL code, OpenBSD developers tend to stick with their ISCL-styled licence for stuff in base. Though I suppose the CDDL code could be made as a module, but module support in OpenBSD is kinda on the way out, is it not?

    2. By Anonymous Coward (74.115.21.120) on

      > Anyone interested in diving into ZFS?

      ZFS isn't free, its CDDL.

      Comments

      1. By Anonymous Coward (193.63.217.208) on

        > > Anyone interested in diving into ZFS?
        >
        > ZFS isn't free, its CDDL.

        The Solaris implementation is CDDL but a re-implementation could be free? I'd hazard a guess that to integrate ZFS into OpenBSD would be a re-implementation.

        Comments

        1. By nomercy (63.148.127.226) on

          > > > Anyone interested in diving into ZFS?
          > >
          > > ZFS isn't free, its CDDL.
          >
          > The Solaris implementation is CDDL but a re-implementation could be free? I'd hazard a guess that to integrate ZFS into OpenBSD would be a re-implementation.

          Yes, I'm aware of the license. The Sun folks have been receptive and helpful towards my efforts and they acknowledge the issue with the license. I've decided to make it work on openbsd so that the devs can take it and audit it, rewrite it and give us our own implementation that will work better on openbsd (because it was designed for it).

        2. By sthen (85.158.44.149) on

          > > > Anyone interested in diving into ZFS?
          > >
          > > ZFS isn't free, its CDDL.
          >
          > The Solaris implementation is CDDL but a re-implementation could be free?

          There are a bunch of patents relating to ZFS. CDDL gives you license to use them, a re-implementation does not.

        3. By Anonymous Coward (74.115.21.120) on

          > > > Anyone interested in diving into ZFS?
          > >
          > > ZFS isn't free, its CDDL.
          >
          > The Solaris implementation is CDDL but a re-implementation could be free? I'd hazard a guess that to integrate ZFS into OpenBSD would be a re-implementation.

          Why would you go through all the effort of re-implimenting it, only to be sued by Sun regardless of how careful you were? Just write your own filesystem with the features of ZFS,

          Comments

          1. By Nate (Nate) on

            > > > > Anyone interested in diving into ZFS?
            > > >
            > > > ZFS isn't free, its CDDL.
            > >
            > > The Solaris implementation is CDDL but a re-implementation could be free? I'd hazard a guess that to integrate ZFS into OpenBSD would be a re-implementation.
            >
            > Why would you go through all the effort of re-implimenting it, only to be sued by Sun regardless of how careful you were? Just write your own filesystem with the features of ZFS,

            In most of the world noone would care about re-implementing it, because in the real world software cannot be patented and anything and everything can be reverse engineered.

            Comments

            1. By Anonymous Coward (207.59.237.99) on

              > In most of the world noone would care about re-implementing it, because in the real world software cannot be patented and anything and everything can be reverse engineered.

              It doesn't matter if "most of the world" doesn't care if Sun's lawyers do.

  6. By Brian Raaen (rhemasound) info@rhemasound.org on http://www.rhemasound.org

    I have been looking into creating a fileserver in the near future that has 1.5 TB. Recently I have been debating about if I would install Debian or OpenBSD on it. On Debian I could set up LVM and dynamically resize the partitions (i.e. expand them as they grow) and resize the XFS filesystems. Is it possable to do something similar on OpenBSD, or is this something this hackathon may be working on. I am very intrested in seeing what changes happen to patitioning/filesystems/raid as a result of this hackathon. Maybe I will be able to set up the fileserver using OpenBSD... Thanks for all your hard work.

    Comments

    1. By sthen (85.158.44.149) on

      > I have been looking into creating a fileserver in the near future that has 1.5 TB. Recently I have been debating about if I would install Debian or OpenBSD on it. On Debian I could set up LVM and dynamically resize the partitions (i.e. expand them as they grow) and resize the XFS filesystems. Is it possable to do something similar on OpenBSD

      Yes, with growfs(8) and ccd(4). Setup the ccd from the start if you want this, since it will be...at least fiddly...to convert afterwards. Backups are highly recommended when making this sort of change to the filesystem (on any OS).

      UFS, however, runs out of block numbers so you can't have 1.5TB in a single partition (even if you do have enough RAM to fsck it). UFS2 would address that, OpenBSD doesn't currently have it though (it's unlikely you could convert a partition directly from UFS to UFS2, btw).

      You can, of course, mount separate partitions (or separate ccds) on different mount points to bypass the 1TB UFS max though.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]