The presenter of this session was Richard Jones, who I've had the pleasure of being in sessions before. A very good speaker, and I always take away something good about whatever the topic is. He is also one of the CoolBlog people, with his Novell blog here.
That said, the session was very good. This was a file-system primer for all the many and various file-systems you can find on SLES and OES. It also included some time on the various access protocols such as Samba, NCP Server, and NetATalk.
Samba, as it sits right now, is at something of a crossroads. The version shipping with SLES9 has issues when being pounded on by lots of connections which would make it completely unsuitable for a server that the entire campus maps to. Our WUF-cluster NetWare servers frequently have up to 7000 simultanious connections, and Samba would melt under that kind of work-load. Version 4 is aiming to fix a lot of that, but is still too buggy and didn't made the code-freeze date for SLES10. Expect it in SLES11 in 18-36 months. V4 can also act as a Domain Controller in an AD domain, which is a very interesting development.
NCP Server is faster than NetWare for two primary reasons. One, when they ported it to Linux the dev-team rewrote 85% of the code to get rid of assumptions that were designed into the NCP-on-NetWare server back in 1989. Specifically, NCP-on-NetWare can run in 32 megs of RAM just fine. You can't get a server that scanty on memory any more, so they wrote it to be more piggy about I/O resources. Second, they removed all hints of IPX from the code. These two things combined are why NCP-on-Linux is faster. And Richard indirectly mentioned my benchmark in January, which was neat.
In terms of futures, NCPServ on Linux will soon support Kerberos. This will, in theory, permit a single login for AD Domains and eDirectory stuff. Neat.
As for Apple.... the NetATalk in SLES9 only supports the version of AFP that came with OS9. At the time of the SLES9 code-freeze the OSX support was cruddy. That isn't the case for SLES10, so NetATalk v2 is included in it. And it includes full OSX support, including long-password support!
Richard also gave some hints as to the future of NSS on OES. Right now the goal is to maintain datastructure compatibility with the NetWare NSS, so there aren't going to be a lot of new features developed soon. There will be an X86-64 native code module built in order to support NSS on 64-bit Linux machines (it IS a kernel module), but the code structure on the file-system will still remain as is.
As for desires, and we're talking several years out, include the ability to do background rebuilds, do cluster parallel file serving, and getting rid of the 8TB volume size restriction.
The other neat thing in this session was the coverage of Cluster Parallel filesystems, and what they're good for. This is a facinating topic, since it can provide a single datasource with multiple block-level access to data. No need to shim it over NFS, it happens in kernel over the I/O subsystem. Not network I/O. This can provide serious performance gains over NFS in certain cases.
Tags: novell, brainshare
That said, the session was very good. This was a file-system primer for all the many and various file-systems you can find on SLES and OES. It also included some time on the various access protocols such as Samba, NCP Server, and NetATalk.
Samba, as it sits right now, is at something of a crossroads. The version shipping with SLES9 has issues when being pounded on by lots of connections which would make it completely unsuitable for a server that the entire campus maps to. Our WUF-cluster NetWare servers frequently have up to 7000 simultanious connections, and Samba would melt under that kind of work-load. Version 4 is aiming to fix a lot of that, but is still too buggy and didn't made the code-freeze date for SLES10. Expect it in SLES11 in 18-36 months. V4 can also act as a Domain Controller in an AD domain, which is a very interesting development.
NCP Server is faster than NetWare for two primary reasons. One, when they ported it to Linux the dev-team rewrote 85% of the code to get rid of assumptions that were designed into the NCP-on-NetWare server back in 1989. Specifically, NCP-on-NetWare can run in 32 megs of RAM just fine. You can't get a server that scanty on memory any more, so they wrote it to be more piggy about I/O resources. Second, they removed all hints of IPX from the code. These two things combined are why NCP-on-Linux is faster. And Richard indirectly mentioned my benchmark in January, which was neat.
In terms of futures, NCPServ on Linux will soon support Kerberos. This will, in theory, permit a single login for AD Domains and eDirectory stuff. Neat.
As for Apple.... the NetATalk in SLES9 only supports the version of AFP that came with OS9. At the time of the SLES9 code-freeze the OSX support was cruddy. That isn't the case for SLES10, so NetATalk v2 is included in it. And it includes full OSX support, including long-password support!
Richard also gave some hints as to the future of NSS on OES. Right now the goal is to maintain datastructure compatibility with the NetWare NSS, so there aren't going to be a lot of new features developed soon. There will be an X86-64 native code module built in order to support NSS on 64-bit Linux machines (it IS a kernel module), but the code structure on the file-system will still remain as is.
As for desires, and we're talking several years out, include the ability to do background rebuilds, do cluster parallel file serving, and getting rid of the 8TB volume size restriction.
The other neat thing in this session was the coverage of Cluster Parallel filesystems, and what they're good for. This is a facinating topic, since it can provide a single datasource with multiple block-level access to data. No need to shim it over NFS, it happens in kernel over the I/O subsystem. Not network I/O. This can provide serious performance gains over NFS in certain cases.
Tags: novell, brainshare