Drive Configuration Database needs to be refreshed?

[Letni]

Experts,

I ended up purchasing a new machine to run my FreeNAS against (physically move 5 SATA drives from the old machine to the new one on a pre-existing FreeNAS setup) and I'm concerned about the "configuration database" sort of representing the old drive order (when the RAID-Z pool was originally configured).

When moving from one machine to another, I re-ordered the drives to allow optimal air flow for the hottest drives. Everything came across just fine (zpool comes online and all mount points are where they should be, however if I click the "View Disks" option, I see that all the /dev/adaX devices do not match what FreeNAS THINKS they should be (the original drive order from my first machine). See Example:



Another thing to note is that after I moved to a new server, I used the GUI to transition a 1 TB drive over to a 2 TB drive within the pool. This was done by plugging the new drive into the new server via USB (while the old 1 TB drive still in the machine), using the "Replace" Feature, letting it resilver, then detaching the OLD drive (while still in the server) and then performing a full shutdown and doing a cold swap. This resulted in the the new 2 TB drive successfully replacing the 1 TB drive, but now Drive Configuration Database reports this as ID 9 (see attachment above) instead of the original ID of 3 and if I click details, the Drive database sees this as a USB drive still (/dev/da1)



Anyone have any suggestions how to rebuild the drive configuration database (or refresh it) in order to have everything match properly between the drive database and what the disks are actually discovered as?

Thanks much.

LetnI

 

[ProtoSD]

The only suggestion I have is to export the pool from the COMMAND LINE, then with the right incantation of sqlite3 commands delete the corresponding entries from /data/freenas-v1.db, and then try doing the Auto Import... There's no guarantees it'll rebuild things the way they were before, but it won't cause any harm to your pool/data, but it should do what you want.

I'm almost ready to post a new tutorial that covers the sqlite3 etc. that you would need to do this. I'll try to update this post with a link when it's ready.

EDIT: Here's a link to the tutorial

http://protosd.blogspot.com/2011/12/useful-commands-for-diagnosingmanaging.html

 

[Letni]

Thanks for the reply.. Couple of questions..

1. I realized I posted this in how-to's.. Could this be moved to the Help and Support Forum :)
2. I noticed that trying to export my zfs pool requires me to destroy all my share information.. Is there any way to preserve this?

Thanks

 

[ProtoSD]

I didn't notice that you posted in the HowTo section, but thanks for mentioning it, I'll move it.

I forgot about export destroying your share info, disregard that suggestion.

I'm oh so close to finishing up my tutorial, trying to get the formatting consistent is a pain! ;)

Give me a little bit and I'll post some more detailed info specific to what you want to do.

 

[ProtoSD]

Ok LetnI,

Let me summarize what I think you need to do:

Backup your /data/freenas-v1.db file

Export your pool from the command line

Delete the proper entries from the database

Auto Import from the GUI



Let's start with these commands to see what your database has for you disks/volume:

sqlite3 /data/freenas-v1.db "select * from storage_volume;"

sqlite3 /data/freenas-v1.db "select * from storage_disk;"


Post the results from those and we'll figure out the next steps.

EDIT: Throw in the output from "zpool status -v" AND "sysctl kern.disks" for good measure too :)

 

[Letni]

Thanks for the effort to reverse engineer a solution, but I believe I have a working solution that doesn't require as much technical background (even though I know what you're getting for with the questions above since I have an extensive technical background). Here is what I ended up doing with my 8.0.3-p1 install:

1. Backup up the config (of course for good practice)
2. I disabled any services that require mount points (afp,cifs,tftp,ftp,nfs,iscsi,etc)
3. export the ZFS filesystem (make sure uncheck the wipe data and uncheck remove shares)
4. Re import the ZFS filesystem with the "Auto Import Volume" button
5. Re-enable any services that utilize the mountpoints

This certainly fixed the database configuration with the drive, with the following observed behaviors:
1. The FreeBSD block devices still are ordered by the original order of what the ZFS pool was created in (the mirror positions) - i'm assuming its detected by the UUID
2. the ID field (the database index) still increases (instead of being 1-5, it is now 8-13), which shouldn't have any bearing of operation.
3. Clicking the Edit Disk button shows under the name the block device AND the partition p2

I look forward to your guide to do a little more hacking with this product, if only to learn more "detailed" functionality in order to FreeNAS more robust from a "stock" operation.

 

[ProtoSD]

Thanks for the followup. That's an interesting approach I hadn't considered and is definitely a bit less technical. Glad you got it working the way you wanted it.

 

[Letni]

Well, my though is that something should be rhobust enough to handle basic admistrative tasks; ie it should "just work" if you're going to consider it production worthy. Where my experience so far with this product has been generally successful, I certainly see room for improving reliability (error checking), especially when it comes to making changes when it is considered "live" and you're relying on it to not destroy your data.

Overall it is one of the coolest products I have used in my "home infrastructre", especially having a SAN storage admin background. Once again, thank you and everyone in the forums to help keep development moving forward :)

 

[ProtoSD]

I completely agree and I know the developers are very responsive to suggestions & feedback, but at the same time they're under a lot of pressure from people whining about non-core features like media servers, printing, plugins, blah-blah-blah. Also, I think interest in FreeNAS 8 exceeded what they probably expected and they're really trying to keep up. I'm not making any excuses, I know there are certain things that should work properly before the bells & whistles and some of those things have gone without the attention they deserve. In the end it is a very cool product and with a little patience and time all the "important" details will be fixed. :)

Welcome to the FreeNAS 8 forums!