Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems Hardware

American Megatrends's NAS based on custom FreeBSD 155

Posted by Nik from the no-such-thing-as-too-much-disk dept.
Asmodai writes "American Megatrends unveiled its StorTrends NAS software with NDMP support. This piece of software, which plugs into the StorTrends and ServTrends storage solutions, is a custom developed FreeBSD. Looks interesting for those who are interested in NAS and SAN and the subsequent managing and monitoring." It's interesting that this press release (because that's what it is) mentions FreeBSD by name.
This discussion has been archived. No new comments can be posted.

American Megatrends's NAS based on custom FreeBSD More

American Megatrends's NAS based on custom FreeBSD

Comments Filter:

  • Truly free (Score:3, Insightful)

    by Ulwarth ( 458420 ) on Tuesday September 18, 2001 @02:41PM (#2316829) Homepage
    This is what the BSD'ers mean when they say that the BSD license is truly free, because you can use it for anything.

    Let's face it, the GPL is more "selfish" - we just don't see it that way because we are comparing it to proprietary software licensing.
    • The BSD license is my favorite, because it not a viral license, like the GPL. Most of the code I write for public use now is under it; whereas about six months ago I was toying with GPL.


      Besides, FreeBSD actually is a very well known OS in the web-hosting/ISP realm. That's where I first learned of it, and where many of my friends still use it. It's also rather addicting :)


      -WS

    • To each his own. The reason I prefer the GPL is that I know that people building on my work have to contribute their improvements back to the community. I think that's fair: they got something for free, they should give something back.

      I can see why companies like Apple and AMI might choose to keep their patches to themselves, and I suppose if the BSD people don't mind then that's Ok, but I think that in the long run software under GPL will go further. If the NAS software were released then AMI might lose a competitive edge in the short term, but they also lose out on features that those competitors add to the product.

      Similarly with Apple. The BSDs are solid and in some ways better than Linux, but IBM and others are scaling Linux up to massive systems. Now Apple is trying to push OsX into the server market and they're going to miss out on those developments. So they got to keep some enhancements to themselves, but they lose out on other people's technology.

      • FreeBSD gained the NetGraph code because it eventually came too difficult for the third party to cost effectively roll the FreeBSD source changes into their custom version. (I forget the company name, they're part of IBM now IIRC.)

        • They were called Whistle and their flagship (only?) product was the InterJet.

          They also contributed divert sockets and I believe they funded the development of soft updates.
      • >I can see why companies like Apple and AMI might choose to keep their
        > patches to themselves,


        Except for the minor detail that Apple *doesn't* keep them to themselves. They sent massive number of bugfixes back, and released Darwin under a free license. . .


        hawk

        • That's interesting. I knew they'd released Darwin, but I always thought (ok, assumed) they held on to bits. Are the drivers available? What about the file system changes?

          Does that mean you can run an Apple box with Darwin and have everything work except the GUI?

          • Yes. yes. yes. :)


            Not just on an apple box, ut on a generic x86 box!


            I actually have a paper on the economics involved that was presented last summer. It's at

            http://www.personal.psu.edu/reh18/research/01.sc e/ Open_Source.conference.ps


            I'll be adding a longer section on when a viral license makes sense, as well as a brief section on when a VIRAL licesnes has economic advantages (after discussion there, it's close to irrelevant) and a short literature review before it goes to a journal. Unlike the rest of the economics I do, this one has no math beyond addition, and, even more amazingly, no greek characters.


            Darwin is closely tied to FreeBSD now; Jordan Hubbard now works for them.


            In a nutshell, Darwin is not a a distinguishing product for apple, but rather a necessary component. It is less expensive for apple to keep to the public base and benefit from joint maintenance on Darwin than to keep private patches which must be maintained. There is a gain from making it all public, and no benefit to keeping any piece of Darwin private.


            hawk

            • An interesting article. I'd love to see the final copy.

              Question: Wouldn't it make more sense for Apple to release under a viral license than a public licenese? Under the public license there's the risk that a competitor will build on Darwin and not release the source back to Apple. With a viral license a competitor can still build on Darwin, but at least Apple could see some benefit.

              This comes back to my personal reason for choosing GPL: I'd like others to build on my work, but I'd like to get something back if they do so.

              On a larger scale, we've got IBM, SGI, and Compaq (all competitors) contributing to the Linux kernel. I can't imagine that IBM, for example, would port their JFS to Linux if they thought Compaq could integrate it into Tru64 and use it to poach IBM's customers. The GPL ensures that everybody has to play by the same rules, so there is less risk.

              • > An interesting article. I'd love to see the final copy.


                I actually submitted it here after the conference, but they never took nor accepted it . . .


                > Question: Wouldn't it make more sense for Apple to release under a
                > viral license than a public licenese?


                apparently not :)


                Under the public license there's
                > the risk that a competitor will build on Darwin and not release the
                > source back to Apple. With a viral license a competitor can still
                > build on Darwin, but at least Apple could see some benefit.


                That was my initial impression, and relates to the material I need to supplement.


                There's a couple of things going on here. The first is that Apple sees no harm from someone running off with the code; they're no worse off than before. But Apple really has no competitors--or even potential competitors--for Darwin. Darwin is like a hard drive or memory chip for Apple; it's a commodity part used to build their specialized product. Apple would just as happily use FreeBSD, NetBSD, Linux, or MS-DOS underneath if it had all the needed elements and was stable.


                Anyway, another firm has the same incentives as apple to contribute changes back to the common base. The competitor also can wander off with any of the *BSD for a base, and these are likely to be about as close as Darwin to what is needed for an arbitrary project--either will require massive modification, and if the changes aren't returned, the company is on its own for maintenance.


                This leaves minimal chances for someone to run off with it, and no problem for apple if someone does (it saddles itself with unnecessary costs!)


                On the other hand, if Apple went viral rather than public, it saddles *itself* with that license with regard to any contributions from the outside. This limits apple's options to later fork off on one-off projects--say, a tivo-like device.


                Overall, there appears to be no net cost to Apple for choosing public over viral, and a couple of gains.


                There's a bit more. One of the thoughts that came back from the conferrence is that generally, code must be so heavily modified to use for something else that lost revenue from the "wandered" variation is probably nil (there's not a huge advantage to the competitor in using the code base). Another is that public licenses give better ability to mix and match pieces under different public licenses, whereas viral licenses are incompatible with each other and, in many cases, third party closed source software.


                Finally, the public license precludes a reaction that can fairly be characterized as "rabid" over suspected "violations"--this is just a hassle that firms don't need.


                hawk

                • >On a larger scale, we've got IBM, SGI, and Compaq (all competitors)
                  >contributing to the Linux kernel. I can't imagine that IBM, for
                  >example, would port their JFS to Linux if they thought Compaq could
                  >integrate it into Tru64 and use it to poach IBM's customers. The GPL
                  >ensures that everybody has to play by the same rules, so there is less
                  >risk.


                  They're in the same situation, with linux being a commodity part. None of these firms have a real interest in having their own flavor of unix; it's not practical to distinguish a unix enough to be a competitive advantage in a small system markets. These firms sell hardware and consulting; having a reliable unix to slap on the machines is necessary. [as a side note, this is Linux' biggest contribution to *nix: it provides a common reference point without anyone having to accept his competitor's version.]


                  Note that IBM pays a price if the JFS stuff is GPL'd: They can't use changes to it in their other systems (AIX), either. I suspect that they'd be better off in that regard with a public license . . .


                  hawk

    • {sigh} Another retarded arguement about which license is "more free."

      How about "Neither." Each license caters to different situations better that the other. One is only "more free" than the other depeding on what you want to do / how you want to use the software.

      Of course, that won't stop the parent post's bubblehead advocate (nor, I fear most of the responses to it) from yet again turning this topic into another license pissing match.
      • I'm not going to start a license pissing match. I only suggest that you do a feature comparison between various licenses. One of the things you should compare is "Am I free to use a new license on my derivative work". The answer with the GPL is of course no. The answer with the BSD-licensed code... well, I'll leave that as an exercise to the reader.

    • Please everyone, spare us the BSD vs. GPL License Advocacy War this time around... I would think the entire Slashdot community already has a basic grasp of the philosophies behing each by now.
  • Anyone have an idea why they chose FreeBSD over other alternatives?
    • Since all you want are some ideas:

      * It's low cost.
      * It allows for closed source distribution.* It's solid, stable code with heavy ties to ISPs (who would use such devices)
      * FreeBSD is open source and future improvements or bug fixes can be rolled in without licensing fees/issues.
      • Ditto (low cost, no GPL, publix fixes, stable).

        Also, it's quick to implement. Any reasonable sysadmin can make a NAS server out of a machine and OS they already know. Installing and administering a NAS server is what the masses are trying to avoid when they buy an "appliance". In many cases, a NAS appliance is simply a server with a quick installation process and an easy to use configuration interface.

        Here's what I think everyone uses...

        Procom (started with BSD, FreeBSD?)
        VA Linux (pre-implosion, based on Linux with ext3 & Mylex extensions)
        Cobalt (Linux)
        Sun (remember the Netra NFS server? Solaris)
        Dell (Microsoft-powered NAS)
        Compaq (Microsoft-powered NAS)
        Maxtor (Microsoft-powered NAS)
        Novell (yes, they have one, supposedly based on top of Netware-derived platform)
        Netapp (custom OS, but suspect it was BSD-derived in early years)
        EMC Clariion (VxWorks + Crosstor)
        EMC Celerra (own RTOS + Linux control station)
        MTI (older Crosstor on their own RTOS?)
        Auspex (own RTOS[?] supported by Windows or SunOS control station)
        AMI (FreeBSD)
        ... and countless others.

        The underlying theme is "go with what you know". Each has their benefits and drawbacks. The companies have to support the products they create. What OS they know how to support probably influenced the underlying OS they used to implement their product.

        AMI knows motherboards, BIOS, and RAID controllers. The software needed to make their hardware into a server was already available with FreeBSD and ported applications. Not that it's a trvial task, but all that they needed to add was a GUI, maybe a front panel, a simple installation process and some support for the product to keep their customers from having to "administer" a "server". Instead, the customers "configure" their "appliance".

        The AMI products seem like good solutions for workgroups, but some caveats might apply:
        - redundancy - seem to have little to no high availability features outside of the RAID controller
        - heat - installing a few here and there are fine, but thinking you can easily put 320 drives in a 40U rack might not be prudent
        - backup costs - Veritas NDMP slave licenses aren't cheap (but perhaps others are?)
        - performance - there are higher-end products on the market for those that need more throughput or I/O operations per second

        -ez

    • Reminds me of an answer I read once, attributed to Torvalds:

      Other than the fact Linux has a cool name, could someone explain why I should use Linux over BSD?

      No. That's it. The cool name, that is.

      Zac

      • Re:Why FreeBSD? (Score:3, Interesting)

        by spudnic ( 32107 )
        I have actually had a (semi-tech) client refuse to use FreeBSD based on the devil mascot. I think it's rather foolish, but they said that they didn't want their company to be associated with satanic symbols. Apparently after pitching the idea to use FreeBSD, he went on the 'net and saw the logo.

        We used Linux for their application instead and everything is working well. I wonder if he would have been offended by a fish?

        Has anyone else run across anything like this?
        • load "linux",8,1
          Love the sig!
    • Well,

      AMI was nice enough to totally open up their specs to the FreeBSD developers a while ago. I'm happily using a MegaRAID 1400 right now. The driver support is incredible. It's rock solid stable. They probably chose FreeBSD because it's rock solid, reliable, free(as in BSD license), and their hardware loves it. Linux would have been a fine option, but they are already very friendly with the BSD crowd. The microsoft offering might have even been an option, but why bother. With FreeBSD they'll have automatic access to a huge talent pool if they need help, and it won't cost a dime. Plus they get the source code. Given all that, I think they made the smartest choice.

  • Love-hate relationship? (Score:4, Interesting)

    by embobo ( 1520 ) on Tuesday September 18, 2001 @02:57PM (#2316948) Homepage
    I've never had a custom-designed system based on FreeBSD (or Linux) but I would think that it would drive me insane, knowing that it was based on FreeBSD, but unable to use any of the flexibility FreeBSD offers.

    Suppose, for example, the thing didn't support ftp. You know FreeBSD supports proftpd but I bet you are forbidden from installing it on the box. Suppose there is a huge bug in the mta on the box (never!). Do you wait for the vendor to supply a patch or do you start hacking?

    The situation is similar to using a package manager. Whenever I install SuSE I try to keep it purely RPM-based but inveitably there is some piece of software I end up compiling myself, without making it a package before installing. From that point on I abandon yast and SuSE config because they don't know about that software and will happily trounce it's config files if one isn't careful. (Strangely, I never worry installing a port on a FreeBSD box. I'm more confident that the port isn't going to be sticking its nose where it doesn't belong.)
    • yes, i too have a love-hate relationship with package management. the solutions i like the most are debian's apt/dpkg and gentoo's ports.

      gentoo compiles everything, but doesnt have all that meny scripts for all the software i like to use.
      while debian does have everything i could think of. just how do i use apt to d/l and compile? also some things like vim i like to have strange options enabled at compile time, how would i choose what options?

      also there is meta package managemnet, that is managing packages on lots of boxen.

      • bash-2.00# apt-get builddep program
        # This gets your build dependencies

        bash-2.00# dpkg-deb -e program.deb
        bash-2.00# dpkg-deb -x program.deb
        # Extract the package itself, and it's control files

        # Now, edit the configuration, patch files, edit control files, edit make files

        bash-2.00# dpkg-deb -b source-dir
        # This will build a .deb package for you

        bash-2.00# dpkg -i program.deb
    • Suppose, for example, the thing didn't support ftp. You know FreeBSD supports proftpd but I bet you are forbidden from installing it on the box. Suppose there is a huge bug in the mta on the box (never!). Do you wait for the vendor to supply a patch or do you start hacking?

      If I recall correctly, Network Appliance servers run on a modified version of BSD as well. Simply put, you don't hack, ever. When you are running a database of several terabytes a NAS box; there is a reason you are paying several million dollars for the hardware: vendor support and accountability. I was on a project must like this in the classified world. If you are caught hacking into a box (even to fix something the vendor should be fixing), you are generally escorted out by a pair of large marines. In many places (not all), there is a zero hacking policy on multi-million dollar boxes that run critical systems.

      • If I recall correctly, Network Appliance servers run on a modified version of BSD as well.

        They don't. They use a derived-from-BSD TCP/IP stack, and some other ported-from-BSD code like dump, but it's a homebrew, minimalist kernel.

    • I've never had a custom-designed system based on FreeBSD (or Linux) but I would think that it would drive me insane, knowing that it was based on FreeBSD, but unable to use any of the flexibility FreeBSD offers.

      Note that this is no different with Linux-based systems.

      The TiVo is a good example. Version 2.5 of the software signs all of the files in / and /etc. If the signatures don't match, the files are replaced with their original versions. If this doesn't succeed, the system reboots (rinse and repeat). Even though their kernel modifications are availble, it doesn't do you a bit of good to allow you access to the TiVo that you bought and paid for. (Note that the widely-known hard drive modifications didn't require any access to the source; however, the TiVoNet modification, which doesn't work on DirecTiVos, did benefit from this information.)

      There are a number of Linux-based systems for which this is true. I personally think that it's a pretty big deficiency of the GPL that it doesn't require access to be provided to allow the owner modify the system on which the source is used. Ironic, since the GPL was supposedly created because Richard Stallman was unable to modify the operation of a system that he controlled...
      • >I personally think that it's a pretty big deficiency of the GPL that it
        >doesn't require access to be provided to allow the owner modify the
        >system on which the source is used.


        This would have the result of banning any ROM--or at least those soldered
        to the mother board . . .


        hawk

    • You perhaps haven't worked in a real environment...
      When you buy a NAS box or something.. you aren't concerned about it being super multi-purpose.

      I don't *care* if I can install a web server on a box or not.. when I want a web server, I buy it.

      Same goes for Unix. I mean, it's nice knowing some of your servers can double as other things... (more difficult/prohibitive with windows)... but you still don't do it. When you build a big database server.. you don't use it as your web server as well. Etc... etc.. etc..

  • The device supports SMB/CIFS and NFS, unsurprisingly as those are the two most common file-sharing protocols at the moment. It's interesting though that, considering they're using FreeBSD, they didn't include AppleTalk support (easily available via the ports tree). It may be that with the advent of OS X, they think NFS is enough for the entire non-Win32 universe.

    • interesting though that, considering they're using FreeBSD, they didn't include AppleTalk support (easily available via the ports tree). It may be that with the advent of OS X, they think NFS is enough for the entire non-Win32 universe.

      Not at all. AFP and NCP support are on the way, and will be supported in future versions.

    • Heh, with the advent of OS X.1's built-in SMB support, maybe they think SMB and NFS are enough for the whole universe.

      AppleShare (you misspelled it "AppleTalk") support would be nice, but I get the feeling that the market is just too small and OS X.1's support of SMB natively will make it kind of kind of moot, even among Mac users.
  • Considering that jordan et al are always working on freebsd, there's no reason why they would not depend on the project again later for fixes etc...

    -s
  • It is truly remarkable and rather unusual that they revealed that there's a FreeBSD working under the hood.

    It's nice to see that FreeBSD gets more and more recognition und I hope 5.0 will be a milestone, once it is out next year. Keep up the good work.
    • RAIDZone NAS states quite clearly that they use Linux...

      And IDE drives!

      IDE is the way to go, recently built a server similar to the TB server featured on slashdot... 167Megs/Sec sustained read from the RAID. (64 bit PCI bus)
    • I think maybe 5.2 will be a milestone. 5.0 is likely to be a beta in all but name. This is not intended as a put-down of the FreeBSD Project, btw.
      • You know what I was talking about, a Dot-Zero release is most likely a little experimental and not intended for production servers (that's what the FreeBSD folks said themselves in several announcements), but all in all 5.0-RELEASE will hopefully bring in a lot of new features.
        • Indeed; I'm particularly excited by the SMP and threading stuff. If the mandatory access control stuff makes it in (and Robert Watson says he thinks it will), it will be interesting to see what people do with it. That technology could allow FreeBSD to be used in places where freeware has never been used before.
  • So this is just BSD on a flash rom? Or is this all integrated into the Bios, so you just power the machine on and configure? What size is the rom?

    I could do the same thing with a cdrom, burn everything onto CDROM, boot cdrom, and not touch the harddrives. Looks like they just took software and moved it from media to memory.

    • So this is just BSD on a flash rom? Or is this all integrated into the Bios, so you just power the machine on and configure?

      Yes and no. The machine powers on and the OS loads from an IDE flash rom. The system has a default IP and you configure everything through a web browser. The flash is 32MB.

      I could do the same thing with a cdrom, burn everything onto CDROM, boot cdrom, and not touch the harddrives.

      You could, but you'd have to have a CDROM drive in the thing, which takes up valuable space in a 1U or even 3U rackmount server. Also, flash roms have no moving parts, which means one less thing to fail on a machine that needs to run 24/7/365. Also, the flash image can be updated automatically, without opening the box, via FTP. And of course, if you made it yourself, you'd be missing all of the custom hardware in there that does health/disk monitoring/alerting, etc, etc.

      Short version: This is a lot more than justFreeBSD on a flashrom.

  • Ok....

    am I the only one who saw NAS and was wondering why anyone thought there was a market for a machine doing "network audio"?

    I also notice that nowhere does anyone feel the need to explain that NAS means "Network Attached Storage" (which took me a few paragraphs to make the connection to).

    Seriously... some of us know different TLAs.

    -Steve

  • "American Megatrends Inc. (AMI), the leader in storage and computing innovations worldwide, "

    You learn something new every day 8^} Seriouisly though, it's pretty hard to take them seriously when they start off with this kind of obvious bullshit.

  • No long rant here, just a quick explanation.

    FreeBSD is for desktops. OpenBSD is for servers. What BSD is for embedding and system costumization? That's right kids, you use NetBSD!

    Yeah, normally, I'm the first to jump in and confuse people about which BSD is for which, but when you budge up this big, someone's got think clearly here. Now, whose brilliant idea was this? I want to know!

  • Is NetBSD's kernel/NFS performance mature enough? (Score:3, Interesting)

    by albert_tam ( 122783 ) on Wednesday September 19, 2001 @01:39AM (#2318785) Homepage
    I haven't paid much attention to the NetBSD kernel development (especially the NFS part) recently. As far as I know, quite a lot of efforts on "zero copy" were made to the NetBSD kernel in order to beef up the NFS send/receive performance with NICs.

    If I understand correctly, a main bottleneck in the NetBSD kernel is memory copying from the user space to the kernel space.

    Under regular circumstance, network i/o buffers are copied from user processes to kernel on the send side, and from kernel to user processes on the receiving side.

    By implementing this "zero copy" method, the above copying process is eliminated and a gain in the system performance as well as network performance should be seen.

    What I am interested to know is that, how mature is this "zero copy" and the overall NetBSD kernel (particularly NFS and the NIC component) to handle great amount of TCP network i/o.

    Anyone cares to enlighten?
  • I dunno if i'm allowed to discuss this but i don't remember signing a non disclosure agreement so here goes:

    my previous company develops and produces RAID subsystems. about 3 years ago, we thought of developing a NAS solution. there was a lot of discussion on which technology, what type of approach and what would be the most practical solution. we had a severe shortage of software engineers so the plan was put aside for a while. our company just bought a 'NAS solution' from another vendor and placed it inside the RAID box. the 'NAS solution' from the vendor used VxWorks(as reported by nmap), provided SMB, FTP and printer sharing.
    anyway, about a year ago, our company decided to make their own NAS solution(more profit that way). we started work on it. the plan was to use an embedded pc, install a stripped down version of linux, equip it with a very light web server(forgot the name), samba and use cgi (perl and C)for the webministration.

    the hardware guys started integrating a SCSI and network controller on the embedded pc. the plan is basically to put a (small)pc running linux inside the RAID box. and the whole thing would be connected to the network via ethernet. we started testing, playing around and stripping down the applications which will be installed in the embedded pc. we had NO experience on how to make a NAS system. all we did was customize a version of linux to function as a NAS, installed it on an x86 based machine which happens to fit inside the RAID box. and there it is
    I have a LOT of questions. especially to the ppl here on /. on what we did and did wrong:

    1.) we used a 32MB IDE flash disk as the boot device(/dev/hda) and ran all the applications from there. the RAID subsystem(/dev/sda) is just for storage of the data. the IDE flash disk happens to be an off-the-shelf sandisk 32MB compactflash card. i think that decision is a mistake coz i've read that cf cards have a finite amount of read/write cycles. what do you guys think?

    2.) we could have utilized some of the space in /dev/sda as storage for /etc and other config files but the big boys upstairs want the product released asap. there should be a way to isolate the user space from the system space on /dev/sda but we weren't able to explore the possibility further. any ideas and discussion on how this can be achieved?

    3.) i've tried applying for jobs in companies that are doing NAS projects. but they (or their recruiter) demands 5+ years in kernel programming. or an equivalent amount in embedded system development. aside from unloading the unnecessary drivers, we did not do anything inside the kernel. any ideas on what are being integrated into the kernel by these companies?

    4.) i've read a while ago that m$ is making changes to smb. if m$ is successful in making 'proprietary' changes in the smb protocol, would that make most NAS subsystem relying on samba obsolete?

    5.) we were able to open up and play inside a NAS solution offered by Western digital. has anybody played reound with one of these devices (ala i-opener)?

  • Anyone remember when Maxtor decided to switch from FreeBSD to WinNT? Do the reasons Maxtor switched have any basis towards the creation of a new NAS system? My thought on it was microsoft made a deal with Maxtor.

Slashdot Top Deals

Over the shoulder supervision is more a need of the manager than the programming task.

Close