Question about unsupported volume resizing

messenger82's picture

This something wholly unsupported but we're playing around with it anyway for experimental reason. If anyone has a thoughts I would love to hear it.

We have a lab / sand box system using commodity storage. Specifically it's a FreeNAS server. We are using it as an iSCSI target and have setup a series of zvols as device extents. On the client side we have Mac pro's, we use one physical port for the iSCSI network, the other port is virutalized with a connection to our public network and metadata network. We are using globalsan client side to connect to the iSCSI storage. We labeled the LUNs, XSAN let us use them to create a SAN.

So my question, one of the things were playing with is resizing volumes and adjusting storage on the fly (or at least with a restart). So lets say I re-size my zvols on my iSCSI side (which I did) which should create a larger volume on the XSAN side, but it doesn't. The volume stays the same size. So how would I tell XSAN that my LUNs (and subsequently my volume) should be larger?

Yes, this is like crossing the streams with our proton packs. It's just a fun thought experiment about using low cost hardware to take advantage of FCPX's SAN Location benefits in low cost labs.

JSamuel's picture

This sounds like two federation ships crashing into each other at warp speed :shock: :lol:

Off the top of my head: You could cvupdatefs; shutdown the volume; try and modify the DiskType sector value in the .cfg and start the volume again.

In reality StorNext doesn't do dynamic growth, so you should/could be adding a Stripe Group.

Joel Samuel.
/thirtytwo - Apple Consultancy & Direction
Proud sponsor of Xsanity.com

All contributions are my own personal opinions - not those of any entity I represent.

abstractrude's picture

you need to add stripegroup/storage pool to resize volume. it works well. to remove storage from a volume mark the stripe group down. you can do this without restart of system, volume will restart though.

-Trevor Carlson
THUMBWAR

messenger82's picture

Two warp speed ships colliding, that's pretty much what I thought this would be but oddly, and against intuition, it's actually working very well in the sandbox.

While unusual for someone to ask to be flamed, I would love to hear all of the reasons I shouldn't do this in a media centered computer lab...because after testing and everything working well despite my best effort, I can't think of any. Basically this will be for student grade media.

Abstractdude, shifting gears on the fly is something we want to try and do rather than destroy and rebuild volumes. So what your proposing is to add a pool will the virtual storage (zvol) then remove it afterward? I don't mind restarting the volume if need be. Just don't want to restore the volume unless I have to. How would I do this from the GUI or cvadmin?

JSamuel's picture

messenger82 wrote:
How would I do this from the GUI or cvadmin?/quote

http://support.dvsus.com/entries/21655336-Grow-expand-a-StorNext-filesystem

Give this a quick read.

Joel Samuel.
/thirtytwo - Apple Consultancy & Direction
Proud sponsor of Xsanity.com

All contributions are my own personal opinions - not those of any entity I represent.

xsanguy's picture

You can actually grow an Xsan volume by adding more storage pools (out of groups of new LUNs). When you're done, migrate the data off them and remove said pool.

So on your iSCSI side, don't expand your zVols - instead add new ones and use them as new LUNs. It's not quite as flexible but it will work.

I kind of love stuff like this. Test the snot out of it, but for scratch space, student media and/or stuff that doesn't need a backup (i.e. it's on tape or on another SAN) why not? What kind of media are you trying to push across this thing? Compressed video might just work. for some definition of work. (esp if that FreeNAS box has a 10gig connection to the switch) Should get you a single stream of ProRes422.

It'll probably be really slow, but who cares? It works... right... ?

Using Xsan with iSCSI targets in general is going to get interesting - aside from the massive performance hit, there's no reason why it shouldn't work - LUNs are LUNs - kinda.