I was one of the unfortunate people who decided to buy a drobo FS and have lived with incredibly slow speeds for all this time. Now the 5n is out, am I correct in thinking that if I wish to migrate all my hardrive to a 5N, I will suffer 25% performance loss over a set of new disks?
this is shocking service from drobo in my opinion, they should offer some kind of rebate for people who paid a lot of money for a FS and now have no simple upgrade path.
Honestly I don’t know if there will be that 25% of performance loss, but I think it’s plausible as it seems 5N will use the old FS file system. Anyway 5N is so much faster than FS (at least 5x, especially with SSD) that you probably won’t realize that.
I was a previous FS owner and I totally agree with you. FS it’s a very unfortunate model, terribly slow. So slow it was almost unusable, apart backup purposes only.
I preferred to start from an empty 5N and transfer my 3 TB file by file. I think it’s the best solution even if it will take some time. 5N is finally a quick and quiet Drobo (when hard disk spin down it’s virtually silent, FS kept on spinning its fan).
I agree there should have been a sort of internal conversion, to transfer data from old FS pack to new 5N one. But starting from an empty Drobo is also a good way to free some space deleting useless files they could have been stored in the years.
My technic was removing one HD from old one and putting in 5N, then transfer files, then emptying copied ones from FS, removing another HD and so on. Long procedure, but I’m happy I’ve done it now. 
Given what others who have migrated have posted, it’s mainly a theoretical loss.
Fact of the matter is, FS pack in a 5N is not slower than it was in the FS, it’s just potentially slower than a 5N-native pack, and is still much, much, much faster than the FS.
So you are still getting a HUGE speed increase.
We tend to get caught up in the quest for squeezing 100% of the theoretical speed/capacity/value of things, but at some point it becomes arguing about pennies and more effort than it’s worth. A bit of the “squeezing the last of the toothpaste out” scenario.
Besides, converting a filesystem in-place is a nontrivial and potentially risky task. Not only are you risking confusion if the existing filesystem is corrupt, but you’re also stressing all the drives at once, and making the data inaccessible for a while.
OOBE of a migration that leaves your data inaccessible for hours or even days wouldn’t be much fun and I would say is worse than the backup, reformat and restore method. At least with the backup, reformat and restore method you can still see and access your data through the process, it’s just spread out over more than one location.
sounds like we need a Hire-purchase service solution offering from Drobo team…
pay a small amount, get a fresh setup to use and copy to, + a bit for p&p and if you choose to keep the drives you get a discount.
btw squeezing toothpaste is easy - all you need are 2 cotton buds, one on each side, with tight rubberbanded edges, and you slide the buds to the end and get all of it out - try it it works
“Rent a backup populated Drobo” is an interesting concept…
Squeezing the tube is easy, it’s the part left over in the nozzle that’s tough (and arguably a waste of time and should be written off, but everyone values time differently). 
sounds like a job for Rambo
Rent-a-Rambo?
Rambo’s-Drobo-Rentals?
just kidding Rambo, but seriously yes this could be a useful service.
(oh btw when i reach the nossle, i just get a clean/sterilised pair of scissors and cut it open)
Given my experience, I’d say any performance loss from an FS diskpack on a 5N is purely theoretical (see my sig). Grab a 5N, slap your disk pack in, sell the FS. You’ll be much happier. The FS was poky (to be very polite), but the 5N is a completely different beast.
Let me give a very technical perspective of the supposed performance loss. This is what a diskpack is mounted with on an FS:
/dev/sda1 /mnt/DroboFS ext3 rw,noatime,nodiratime,data=ordered 0 0This is what a migrated diskpack looks like in a 5N:
/dev/sda1 /mnt/DroboFS ext4 rw,noatime,nodiratime,barrier=1,data=ordered,discard 0 0Notice that although the filesystem was originally ext3, the 5N will mount it as ext4, using its backward compatibility.
This is what dumpe2fs says about it on the FS:
# dumpe2fs /dev/sda1
dumpe2fs 1.41.10 (10-Feb-2009)
Filesystem volume name: DNAS
Last mounted on: <not available>
Filesystem UUID: 69d3956a-5449-48a6-a673-6e095b32d3f4
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype needs_recovery sparse_super large_file uninit_bg
Filesystem flags: unsigned_directory_hash
Default mount options: (none)And this is what you get from the migrated diskpack on the 5N:
# dumpe2fs /dev/sda1
dumpe2fs 1.42.7 (21-Jan-2013)
Filesystem volume name: DNAS
Last mounted on: /mnt/DroboFS
Filesystem UUID: a1b9f83d-3492-42cb-9685-e8b64246876d
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype needs_recovery sparse_super large_file uninit_bg
Filesystem flags: unsigned_directory_hash
Default mount options: (none)The thing you should be paying attention to are the “Filesystem features.” They are essentially the same. This means that the migration from an FS to a 5N does not change anything with the filesystem, as expected.
But what about a brand new filesystem created on the 5N? According to /etc/init.d/init_fs, this is the command line that creates the filesystem on the diskpack:
/sbin/mkfs.ext4 -i 262144 -K -L DNAS -m 0 -E lazy_itable_init -O dir_index,sparse_super,uninit_bg,^resize_inode ...This is what it looks like when I format a partition using that command:
# dumpe2fs /dev/sda2
dumpe2fs 1.42.7 (21-Jan-2013)
Filesystem volume name: DNAS
Last mounted on: <not available>
Filesystem UUID: 5e474310-f833-43d9-bca5-6c13023589fd
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype extent flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: unsigned_directory_hash
Default mount options: user_xattr aclThese are the new features: “extent”, “flex_bg”, “huge_file”, “dir_nlink”.
Of those, it seems that “extent” and “flex_bg” have an impact on performance. How much exactly is hard to tell because although both “extent” and “flex_bg” should have a significant impact of file creation and deletion, real-life benchmarks can hardly tell the difference ( http://www.phoronix.com/scan.php?page=article&item=ext4_benchmarks&num=1 ).
TL;DR: The FS created an EXT3 filesystem whose attributes are preserved when moved to a 5N, but which is then mounted as EXT4. A brand new EXT4 filesystem created on the 5N possesses new attributes that should improve performance, but it is not clear how much it will make a difference in real-life scenarios.
Edit:
@diamondsw: Do my eyes deceive me or did I just see that a brand new filesystem on a 5N would support extended attributes?! When was this introduced?! I just tried to set extended attributes on that new formatted partition and it failed miserably. Dmesg confirms that user_xattr and acl are not supported by the kernel, although they are supported by the filesystem module.
Dang, ricardo - I locked onto the same thing as I read through the filesystem output. Sadly, for my purposes we’d need both kernel support and Netatalkd 3.0, which as I recall is not on the 5N. Still, nothing saying that both couldn’t be added at some point (although very unlikely).