"Something wrong with this volumes CNID DB..."
4jeg
I have been happily using BMFU for some time, and this just happened.
I upgraded to 3.1 (newer version of netatalk) and the problem
persists.
It started when I had connected to the drive over VPN and during a
transfer it cut out. I have deleted various .Apple files from Drobo /
DroboCapsule. Connecting by SMB seems to work.
When I connect by AFP, it gives the error (in the subject line) and
the drive is read-only. However, if I re-connect (eject and mount) it
seems fine.
The only other tidbit I can offer is that during the VPN trasnfer that
cut out, the contents of one whole folder went missing, but whether
that was me or the machine I am unsure.
Any help would be very appreciated, thanks!
4jeg
" There is something wrong with the volume's CNID DB, using temporary
CNID DB instead. Check server messages for details. Switching to Read-
only mode. "
Cedric
directly to the Mac (firewire) and repaired the disk, as well as the
sparse bundle with Disk Warrior. That solved my problem.
You might try a repair with Disk Utility too.
Good luck.
Cedric
4jeg
Jon Stevens
--
You received this message because you are subscribed to the Google Groups "backmyfruitup" group.
To post to this group, send email to backmy...@googlegroups.com.
To unsubscribe from this group, send email to backmyfruitu...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/backmyfruitup?hl=en.
abadird
covers this?
I have not had success using the methods above to fix the errors. I
noticed the problems after upgrading to bmfu3, but I didn't check on
bmfu2 to see if these problems occurred at that time.
I just did a pin-hole reset on my drobo and then repopulated it from
the copy. I verified the disk using diskUtility and then reconnected
it to the droboShare. Immediately I reinstalled the droboapps:
drobo app admin
add swap
dropbear ssh
bmfu3
upon reboot of the drobo i was unable to mount the droboshare via afp
due to cnid db problems. I immediately reconnected the drobo to the
computer and diskUtility was unable to either verify or repair the
disk. in the past diskWarrior has fixed the issues but in this case I
reset my drobo and repopulated from the copy.
There were no actions on my part in between the initail verification
and the installation of the apps.
Both the drobo and droboshare were replaced by drobo support in the
last 4 weeks due to these issues.
(fyi:
After re-resetting the drobo I repopulated it from the copy and left
it connected to by desktop. I shared it via fileSharing and had the
laptop perform some timeMachine backups. It verified correctly
immediately thereafter, but the next morning (with no other access to
the disk) it failed verification. Somehow this problem occurs with hfs
+ and afp, regardless of droboShare. I did not reconnect it to
droboShare to see if i'd get the cnid db message).
Most people helping me are quick to blame others (drobo blames
droboApps and you, you mentioned a bug in the hfs+ implmentation from
drobo) so i understand I'm fixing these errors by myself. It is for
this reason I'd really like a link to the documentation you mention (a
specific link discussing this issue).
Any ideas/information/link would help.
thanks,
david
p.s. if i can get bmfu working correctly i'll be happy to donate to
the cause!
> > .
Jon Stevens
To unsubscribe from this group, send email to backmyfruitu...@googlegroups.com.
Tobias Hackstock
In other words. DroboShare + HFS = trouble.
That said, this might not be your problem, but it is likely.
Since you have a backup of the data, try using ext3 instead of hfs. This must be done with the Drobo attached to the DroboShare, and using the Dashboard, since a directly connected Drobo will not have that option. You will lose the ability to connect the Drobo directly to the Mac running OSX*. You will gain (maybe) stability. A Linux boot cd/DVD can still be used with the Mac (assuming intel Mac) if you ever need to do a disk check (fsck). You will still be able to use SMB and (after you reinstall BMFU) AFP to connect to the DroboShare.
*there is a ext3 driver for OSX, I believe, that uses MacFUSE, but last I checked MacFUSE is rather flaky and has been abandoned for awhile. It is probably best to just not expect it to work if directy connected.
Apologies if this is a bit offtopic for the BMFU list, but the HFS bugginess is not obvious enough.
- Toby
> To unsubscribe from this group, send email to backmyfruitu...@googlegroups.com.
Jon Stevens
Toby
workcycle/workload. You've mentioned "I don't delete files on my Drobo
and I only use it for TM." Other people do delete things. I know I've
had issues with HFS+, with no improper shutdowns to blame at the time
(UPS), once on live data, and subsequently in testing. I've been error
free with no errors picked up by fsck since switching to ext3 (just
over a year).
There are quite a few posts on drobospace.com about HFS+ issues with
Droboshare. One dealing with segfaults on the DS itself when deleting
files (either over smb or locally on the DS using rm). Another with
instability in general
(http://www.drobospace.com/forums/showthread.php?tid=935). In the
latter discussion, ignore gerd03's abrasiveness, but pay note to
j...@rychter.com, Chrisfull, tonin, daveq in that thread, and also
brickbat in (http://www.drobospace.com/forums/showthread.php?tid=665).
I cannot find it now (perhaps archive.org might have a copy of the old
forums) but there were discussions of DS causing reproducible
corruption when deleting anything after a certain amount of space was
filled when using HFS+.
The default behavior of disabling the journal does not help matters
for cases where the power DOES goes out (but as an artifact of the
lackluster hfs support in Linux, cannot be helped). The battery backed
cache in the Drobo is there to maintain it's knowledge of the disk
layout, and as a block device it can't do much to keep the file system
metadata consistent without a journal.
Also from previous discussion, we used to be in agreement about this:
> Interesting. I noticed the same thing last night. I was having problems
> getting Drobo Dashboard to connect to my Drobo via the DroboShare. It just
> wasn't showing up. So, I connected via USB, ran Disk Utility...
>
> Also note my previous email today... we really should be using ext3. It
> turns out that hfs+ on linux isn't maintained and is buggy. I'm a bit
> shocked that DR recommends this solution at all.
> jon "
I'm glad HFS works for you in your usage, but there is enough personal
and non-personal frustration and empirical evidence to indicate that
there are bugs in the implementation. If I can speculate, these issues
may indeed be part of the problem with the random CNID DB/.Apple*
errors. I have just requested the GPL source to the DS kernel to look
at the hfsplus implementation, which I do not doubt is very similar if
not identical to old vanilla kernel code for HFS+. Since then that
particular fs driver in mainline has been kludged to refuse mounting
of HFS+ partitions >2tb in size due to corruption issues, since nobody
has been annoyed enough to fix it properly yet.
The only thing I fear by looking at it is the realization of a
shroedinbug. If so, all the data you have stored may suddenly
disappear in a puff of logic. If it does, at least it was with good
intentions :-D
schroedinbug: /shroh�din�buhg/, n.
[MIT: from the Schroedinger's Cat thought-experiment in quantum
physics] A design or implementation bug in a program that doesn't
manifest until someone reading source or using the program in an
unusual way notices that it never should have worked, at which point
the program promptly stops working for everybody until fixed. Though
(like bit rot) this sounds impossible, it happens; some programs have
harbored latent schroedinbugs for years. Compare heisenbug, Bohr bug,
mandelbug.
- The Jargon File
Until next time,
- Toby
4jeg
"abadird'.
I tried to copy everything off, after DiskWarrior and Disk Utility
couldn't touch it. I deleted the .Apple* files. So after moving a huge
amount of data back, making new backup images, etc. I am STILL getting
the CNID error. This is after formatting with the Drobo Dashboard
(perhaps I should have wiped more thoroughly with Disk Utility?).
I understand there's some limitation regarding AFP and Time Machine,
but at this point I'm willing to take the chance on backing up
directly to the Drobo via SMB.
I had no problems for a very long time, and now this!
The only thing I can think of is this: I never followed the
instructions of increasing the max backup volume size in the 'Apple
Defaults' file after upgrading (and I'm not sure if I did at the
beginning either). I have two computers with 700 GB backup sparse
images, but it reality I was only at ~500 GB total. Is it possible
that something funny happened by setting the spare image size > 650
GB?
Any help would be great - leaving on a long trip tomorrow night and
I'd love to back up before I go!
Thanks!
4jeg
Should I wipe down the drive with Disk Utility and ensure everything
is 'reset' and try again from scratch?
4jeg
to a clean slate.
4jeg
"What method did you use to delete the .AppleDB file? You deleted it
from Both the AFP "Drobo" and Drobo Capsule share? Were you connected
to the drive using AFP at the time?
Suggest: Connect to the DS using SMB.
make sure you are NOT connected to the DS using AFP.
log in to the DS using SSH
Kill the netatalk daemon.
delete the .AppleDB file from the or /Volumes/Drobo/ directory, using
the command prompt in OSX
mount the sparsebundle in /Volumes/Drobo/DroboCapsule/
delete the .AppleDB file from /Volumes/Drobocapsule/
restart droboshare
done?
- Toby"
This WORKED. I guess connecting manually by SMB was the trick. Thanks
so much!