I looked at CODA for a cluster back in 2004 and decided I'd never
use it.
It's far more complex than any other filesystem I've worked with.
It's the only one that requires a special "log" partition, a special
"metadata" partition, and requires you to enter hex addresses for the
starting locations of certain data blocks.
Consider this paragraph from the CODA manual that tells you how big
the RVM partition should be:
As a rule of thumb, you will need about 3-5% of the total file data
space for recoverable storage. We currently use 4% as a good value under
most circumstances. In our systems the data segment is 90Meg for
approximately 3.2 gigabytes of disk space. By making it smaller, you can
reduce server startup time. However, if you run out of space on the RVM
Data partition, you will be forced to reinitialize the system, a costly
penalty. So, plan accordingly.
Okay, so... I've never used CODA before, and I'm not sure what my
filesystem will look like. There is no way their ancient example
numbers for "3.2 gigabytes" scales up to today's filesystems that are
closer to 3.2 terabytes. How am I supposed to know what initial values
to choose? If I guess wrong, it'll only destroy the entire filesystem.
I can understand inode size... but I can't understand this.
And configuring the RVM (metadata) looks like this (again from the
manual -- those hex values are supposed to be magically chosen and
entered by the user):
$ rdsinit /dev/hdc1 /dev/sdb1
Enter the length of the device /dev/sdb1: 119070700
Going to initialize data file to zero, could take awhile.
done.
rvm_initialize succeeded.
starting address of rvm: 0x50000000
heap len: 0x1000000
static len: 0x100000
nlists: 80
chunksize: 32
rds_zap_heap completed successfully.
rvm_terminate succeeded.
[Note: Use of the decimal value for the length of the device and the use
of hex values for the address and lengths of the next three values.]
I absolutely love that little note... use decimal value for the
first value, and hex for everything else. Don't forget! :) And the
manual says that they use 0x50000000 (or was it 0x500000000? can't
remember) for Intel-based architectures running Linux or FreeBSD... but
nothing about other platforms. The tools, documentation, and skilled
technicians necessary in an emergency just don't seem to be there for CODA.
In short, managing CODA seems to be about on par with managing a
big database. Too complex, too many options, and you need an in-house
expert to keep the thing running.
> /A big item on our wishlist is the ability to both have multiple
hosts writing to the distributed filesystem/
NFS or Samba. Cross-platform, any error message you come across is
guaranteed to show up in a Google search, and any version of Linux comes
with either of these ready to go.
(There are others, like SSHFS and WebDAV, but they don't support
the concept of UIDs and GIDs.)
> /*and* have read-only backup copies on standby hosts (which could
then be converted to active in the event of catastrophe)/
How will this filesystem be used? Is this for a company file
server, or for some real-time shared storage for a public server cluster?
Note that hot mirrors (like CODA or RAID) are only part of the
solution. They won't protect you if you accidentally delete the wrong
file, or if you get rooted by a script kiddie.
I use rsnapshot (which does rsync incrementals like Apple's Time
Machine) run once every hour, to an offsite backup server. My backups
are always online in a read-only fashion, ready for use at any time. If
my primary server melts, then I've lost (at most) an hour of work.
Plus, I have incrementals -- I can instantly see any of my files as they
existed 3 hours, 4 days, or 5 months ago. Using SSH keys it's all
encrypted and fully automatic. And if there's a disaster, I'm not
dealing with any magic partition sizes or other such nonsense -- it's
just files on a disk.
--Derek
On 04/05/2011 04:27 PM, Glenn Stone wrote:
$NEWCOMPANY is having major issues with OCFS, and I'm looking into
alternatives for replacing it. A big item on our wishlist is the ability to
both have multiple hosts writing to the distributed filesystem, *and* have
read-only backup copies on standby hosts (which could then be converted to
active in the event of catastrophe). Coda seems to fit this bill, from what
I've been able to google up. I'm not, however, able to determine if this
thing is still in an R&D phase, or ready for prime time; it seems to maybe
kinda slowly still be being worked on? (Latest RPM's are dated 1/26/2010).
Exploring alternatives,
Glenn
Listen: I'm a politician, which means I'm a cheat and a liar, and when I'm
not kissing babies I'm stealing their lollipops. But it also means I keep my
options open. -- Jeffery Pelt, "Red October"
