Drobo and my typical luck

I’m not gonna lie; this is pretty dry and mostly here for google fodder. Still, this might tickle your nerd-bone.

Not-so-recently I bought a Drobo for storage. I was tired of fake on-motherboard RAID, and I didn’t want to spring for a 3ware RAID card and the associated learning curve. I heard about the Drobo from a friend, and got it and the DroboShare. After having a poor experience with the DroboShare (I wrote a review on NewEgg but the short version: it does less than a linux server) I decided I’d get rid of my existing file server and use my desktop and the Drobo as the server.

Eventually. I was about to move, had projects at work that needed love, and had some planned / unplanned time off. I did the rsync when I had the DroboShare, and didn’t get to play again on my linux box until recently.

I re-ran the rsync to get it back up-to-date. I noticed the rsync had file errors – all of the filenames with non-ascii characters (a not-insignificant amount of my music) always showed up in the transfer list. That was bad news, but I blamed the DroboShare. Who knows how it formatted the Drobo disk pack? Charset could be some obscure ext3 option, and I didn’t care to invest the time to find out. I reformatted using droboview in the linux drobo-utils package. For good measure, I set the LUN size to 4 (meaning the max size would be 4 TB, instead of segmenting into many virtual 2TB disks).

I mounted with errors=remount-ro and ran an rsync. After a couple dozen GB, I started to see “transfer failed – target is read only” and had a looksee in dmesg. Here’s what I got:


[131174.845284] kjournald starting. Commit interval 5 seconds
[131174.817576] EXT3 FS on sdb1, internal journal
[131174.817778] EXT3-fs: mounted filesystem with ordered data mode.
[136948.130539] journal_bmap: journal block not found at offset 12 on sdb1
[136948.130545] Aborting journal on device sdb1.
[136948.140801] EXT3-fs error (device sdb1) in ext3_new_blocks: Journal has aborted
[136948.140895] Remounting filesystem read-only
[136948.143414] __journal_remove_journal_head: freeing b_committed_data
[136948.143438] __journal_remove_journal_head: freeing b_committed_data
[136948.143454] __journal_remove_journal_head: freeing b_committed_data
[136952.123413] __journal_remove_journal_head: freeing b_committed_data
[136952.123672] __journal_remove_journal_head: freeing b_committed_data
[136952.123755] __journal_remove_journal_head: freeing b_committed_data
[136952.123831] __journal_remove_journal_head: freeing b_committed_data
[136952.123906] __journal_remove_journal_head: freeing b_committed_data
[136952.123975] __journal_remove_journal_head: freeing b_committed_data
[136952.123992] __journal_remove_journal_head: freeing b_committed_data
[136952.124006] __journal_remove_journal_head: freeing b_committed_data
[136952.124016] __journal_remove_journal_head: freeing b_committed_data
[136952.124030] __journal_remove_journal_head: freeing b_committed_data
[136952.124043] __journal_remove_journal_head: freeing b_committed_data
[136952.124191] __journal_remove_journal_head: freeing b_committed_data
[136952.124208] __journal_remove_journal_head: freeing b_committed_data
[136952.124280] __journal_remove_journal_head: freeing b_committed_data
[136952.124335] __journal_remove_journal_head: freeing b_committed_data
[136952.124345] __journal_remove_journal_head: freeing b_frozen_data
[136952.124350] __journal_remove_journal_head: freeing b_frozen_data
[136952.124354] __journal_remove_journal_head: freeing b_frozen_data

and this on re-mount:

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so


Aww, dammit. What did droboview do wrong? So i googled for EXT3-fs error dmesg drobo and got an authoritative sounding page with command-line instructions. I can get down with the hands-on version so I can scope out where breaks happen. But lo and behold, it worked just fine. The rsync ran fine, and it unmounted and re-mounted correctly. We’ll see how it goes in the long run, but it’s lookin good for now! If you hear nothing, then I heartily endorse this.

All a mess!

I was just upgrading WordPress and noticed I haven’t said much in a *while*! Not for lack of anything going on, but it’s mostly been personal stuff and work stuff. Seeing as this is already a meta post, I’ll summarize for those following my stream that care (hello, facebook).

Unfail for Linux Network Manager

I use ubuntu (now kubuntu, whatevs) and had the little network manager applet go AWOL on me – it was stuck with “manual configuration” and wouldn’t do its magic for me. Now, I’ve had to write my own nastiness for ifup/down scripts before, so I could cope, but it sucked. I have looked around, but only recently found [a page with the solution to the problem.](https://answers.launchpad.net/ubuntu/+source/knetworkmanager/+question/15308) Life is tastes better now.

Linux Router on the Cheap

[http://www.wi-fiplanet.com/tutorials/article.php/3562391](http://www.wi-fiplanet.com/tutorials/article.php/3562391)

Unfortunately this article doesn’t mention that Linksys *did* stop selling this unit. They sell a different unit (which does not run Linux) under the same name, and took the Linux version and [renamed it the WRT54GL](http://hardware.slashdot.org/article.pl?sid=05/12/01/2326222&from=rss) (the L is for Linux… GET IT?!?) and added $15 to the price. Because of this stupid maneuver I have to ship the one I bought back, and get the new one. Grrr. Hopefully the new firmware is as good as people say, because the WRT54G v5 that I bought (without Linux, with VxWorks) crashed every 4 hours for no reason.