SOLVED Cannot eject RDX removable device

[M.A]

Hello,

Facing an issue with "camcontrol" command here. I'm trying to eject a removable RDX SATA drive. I have already detached the volume from the GUI without an issue but when I press the Eject button on the RDX device it blinks Orange and does nothing.

I tried the Terminal + camcontrol command and here is what happens:

Code:

root@freenas:/mnt/backup # camcontrol stop da0

Unit stopped successfully

root@freenas:/mnt/backup # camcontrol eject da0 -v

Error received from stop unit command

(pass3:ahcich3:0:0:0): START STOP UNIT. CDB: 1b 00 00 00 02 00

(pass3:ahcich3:0:0:0): CAM status: SCSI Status Error

(pass3:ahcich3:0:0:0): SCSI status: Check Condition

(pass3:ahcich3:0:0:0): SCSI sense: ILLEGAL REQUEST asc:53,2 (Medium removal prevented)

Help and pointers greatly appreciated

 

[Chris Moore]

Have you been using this successfully prior to now?
Is this in an environment where you can reboot the server? Sometimes, a full power cycle is the only way to overcome a malfunction.
Admittedly, I am not directly familiar with the hardware, but I have had experience with tape systems and I was reading that these cartridges are intended as a replacement for tape media. I wonder if there is an ejection mechanism like a DLT drive that locks the cartridge in and mechanically pushes it out?
If not, you might be able to simply pull the cartridge out. I have had to disassemble DLT drives and wind the tape out when the mechanics of the drive fails. If there is a mechanical component of the dock that holds the cartridge, it could have failed and then you will need to replace the dock. If it is a transient malfunction, a power cycle might reset it and allow a normal ejection. If that doesn't work, your device could have to be replaced.


Sent from my SAMSUNG-SGH-I537 using Tapatalk

 

[M.A]

Hello Chris,

Thank you for your response and suggestions.

This RDX is pretty new to me. I'm also going this way because I do not want to spend a fortune on a tape device/media. Besides, being basically a SATA disk is much more convenient if/when I want to plug these backup disks into another FreeNAS machine.

I can, but i do not want to, reboot the FreeNAS box. It is the main NAS machine and a reboot will interrupt work.

The RDX setup was a breeze. Simply plug it in and the box detects it. The whole thing took like two minutes and I had a proper backup volume.

There is a hardware button for mechanical ejection yes, but–as I mentioned in my original post– it just blinks Orange and the drive does not eject. When the RDX media is inserted it is quite flush with the unit and very hard to pull out. Besides, such action might actually damage the mechanism because loading/ejection mechanism is DC motor based by the way, like an old VHS player :).

I know it works fine because
- I eject the media Before starting FreeNAS (during POST)
- I load the 1TB media into the drive but I do NOT re-import the volume
- I login into the shell and try to eject the media. The DC motor spins and the media is out very smoothly.

Terminal output look like this

Code:

root@freenas:~ # camcontrol stop da0 -v
Unit stopped successfully
root@freenas:~ # camcontrol eject da0 -v
Unit stopped successfully, Media ejected

I'm just hoping for a command that would kill any dangling relations between the disk and the system and force the ejection.


Sent from my 386SX

 

[Chris Moore]

Beside, such action might actually damage the mechanism because loading/ejection mechanism is DC motor based by the way, like an old VHS player

That was what I was getting at. With the DLT tapes, like a VHS, the tape is pulled into the unit by a motor (mechanical device). Some of the hard drive cartridges I have dealt with have special sockets instead of just using SAS or SATA connections but they are still able to be pulled out manually instead of relying on a motor to drive the cartridge out. If it has a motor, there is likely a locking mechanism, so I retract the suggestion to just pull it out. Sorry.

I can, but i do not want to, reboot the FreeNAS box. It is the main NAS machine and a reboot will interrupt work.

You may need to wait until a time when it would me more convenient, but a reboot may be the only way.

I'm just hoping for a command that would kill any dangling relations between the disk and the system and force the ejection.

I agree, some process still has the drive locked so the software is denying access to eject it. You might be able to identify the process and kill it, but I am not sure what would be causing it.

 

[M.A]

A bit more diagnostics. When the media is inserted into the RDX drive I see this in the terminal

Code:

root@freenas:~ # tail -f /var/log/messages

Jul  2 23:51:52 freenas (da0:ahcich3:0:0:0): dasetgeom: failed to set read capacity advinfo

Jul  2 23:51:52 freenas (da0:ahcich3:0:0:0): CAM status: CCB request was invalid

Jul  2 23:51:52 freenas (da0:ahcich3:0:0:0): dasetgeom: failed to set read capacity advinfo

Jul  2 23:51:52 freenas (da0:ahcich3:0:0:0): CAM status: CCB request was invalid

Jul  2 23:51:52 freenas (da0:ahcich3:0:0:0): dasetgeom: failed to set read capacity advinfo

Jul  2 23:51:52 freenas (da0:ahcich3:0:0:0): CAM status: CCB request was invalid

Jul  2 23:51:52 freenas (da0:ahcich3:0:0:0): dasetgeom: failed to set read capacity advinfo

Jul  2 23:51:52 freenas (da0:ahcich3:0:0:0): CAM status: CCB request was invalid

Jul  2 23:51:52 freenas (da0:ahcich3:0:0:0): dasetgeom: failed to set read capacity advinfo

Jul  2 23:51:52 freenas (da0:ahcich3:0:0:0): CAM status: CCB request was invalid

Could this be a driver issue?. I found one old thread where the user was unable to eject the media after upgrading to V8.2.0. Have no idea which brand/model she/he was using.

 

[M.A]

All is fine now. I found the solution to my problem.

Keeping a tail on messages in a separate Terminal window, while inserting the media, I saw this

Code:

root@freenas:~ # tail -f /var/log/messages
Jul  3 00:11:55 freenas ZFS: vdev state changed, pool_guid=8087050217614909629 vdev_guid=1156168618597268075
Jul  3 00:11:55 freenas (da0:ahcich3:0:0:0): dasetgeom: failed to set read capacity advinfo
Jul  3 00:11:55 freenas (da0:ahcich3:0:0:0): CAM status: CCB request was invalid
Jul  3 00:11:55 freenas (da0:ahcich3:0:0:0): dasetgeom: failed to set read capacity advinfo
Jul  3 00:11:55 freenas (da0:ahcich3:0:0:0): CAM status: CCB request was invalid
Jul  3 00:11:55 freenas (da0:ahcich3:0:0:0): dasetgeom: failed to set read capacity advinfo
Jul  3 00:11:55 freenas (da0:ahcich3:0:0:0): CAM status: CCB request was invalid
Jul  3 00:11:55 freenas (da0:ahcich3:0:0:0): dasetgeom: failed to set read capacity advinfo
Jul  3 00:11:55 freenas (da0:ahcich3:0:0:0): CAM status: CCB request was invalid
Jul  3 00:11:59 freenas GEOM_MIRROR: Device mirror/swap1 launched (2/2).
Jul  3 00:11:59 freenas GEOM_ELI: Device mirror/swap1.eli created.
Jul  3 00:11:59 freenas GEOM_ELI: Encryption: AES-XTS 128
Jul  3 00:11:59 freenas GEOM_ELI:     Crypto: hardware

The interesting lines for me were lines 11 & 12. So I dug a bit around the forum for "GEOM" messages and I found about the "gmirror" command. Reading the MAN/documentation I discovered I can use "gmirror status -ags" to list current status of active swaps. So I ran it in my second Terminal window and I got this

Code:

root@freenas:~ # gmirror status -ags
    swap0  COMPLETE  ada2p1 (ACTIVE)
    swap0  COMPLETE  ada1p1 (ACTIVE)
swap0.sync       N/A  N/A
    swap1  COMPLETE  da0p1 (ACTIVE)
    swap1  COMPLETE  ada0p1 (ACTIVE)
swap1.sync       N/A  N/A

Alrighty... my RDX device is [da0] and on lines 5 & 6 I can see there is still an ACTIVE swap1. Now I use this command

Code:

root@freenas:~ # gmirror stop -fv swap1
Done.

Then I try to eject the media again and it works! :)

Code:

root@freenas:~ # camcontrol eject da0 -v
Unit stopped successfully, Media ejected

So, the correct procedure to remove RDX media would be:

1- GUI > Storage > Select Volume > Detach Volume

2- Terminal > camcontrol devlist

Code:

root@freenas:~ # camcontrol devlist
<ST4000NM0115-1YZ107 SN04>         at scbus0 target 0 lun 0 (pass0,ada0)
<ST4000NM0115-1YZ107 SN04>         at scbus1 target 0 lun 0 (pass1,ada1)
<ST4000NM0115-1YZ107 SN04>         at scbus2 target 0 lun 0 (pass2,ada2)
<TANDBERG RDX 0245>                at scbus3 target 0 lun 0 (pass3,da0) <----- This guy
<SuperMicro SSD SOB20R>            at scbus5 target 0 lun 0 (pass4,ada3)

3- Terminal > camcontrol stop da0 -v

Code:

root@freenas:~ # camcontrol stop da0 -v
Unit stopped successfully

4- Terminal > gmirror status -ags

Code:

root@freenas:~ # gmirror status -ags
    swap0  COMPLETE  ada2p1 (ACTIVE)
    swap0  COMPLETE  ada1p1 (ACTIVE)
swap0.sync       N/A  N/A
    swap1  COMPLETE  da0p1 (ACTIVE)
    swap1  COMPLETE  ada0p1 (ACTIVE)
swap1.sync       N/A  N/A

5- Terminal > gmirror stop -fv swap1

Code:

root@freenas:~ # gmirror stop -fv swap1
Done.

6- Terminal > camcontrol eject da0 -v

Code:

root@freenas:~ # camcontrol eject da0 -v
Unit stopped successfully, Media ejected

I just hope this will help someone else with RDX backups. I also hope this will get fixed in future updates. Thank you Chris for trying to help :)


Cheers

 

[Chris Moore]

I just hope this will help someone else with RDX backups. I also hope this will get fixed in future updates. Thank you Chris for trying to help :)

Sorry I wasn't able to get back to you on this yesterday. It looks like you did some really heroic research here. Thanks for sharing.

Something to know, the system will only create 5 mirrors for swap space, so if you already have enough drives in the system to have 5 mirrors, you would never see this behavior. Based on what you are sharing, it appears that you only have three drives in your storage pool and this removable drive is being paired with the, previously free, third drive to create a swap mirror.

Can I get you to share the output of zpool status?

 

[wblock]

In this situation, the mirror partition is likely to be an ongoing problem. I would delete that partition on the removable drive with gpart.

 

[cobrakiller58]

When you export a pool from the GUI doesn't it disable the swap on the drives associated with that particular pool to allow safe removal?

edit:disable is probably the wrong word unmount is probably more accurate.

 

[Chris Moore]

I am not sure the exact way you are using these removable drives, but I am guessing that you are creating a single disk pool on them, copying data to it, then ejecting the drive. We need to look at that a little, to save you some trouble that you should not be having.
Before you insert another drive, and create a pool on it, do this:
Look on your "System" tab.

Look:

Where it specifies the size of the partition for swap, set that to 0 (zero) and save the setting. Then, when you insert your removable drive and create a pool on it, there will be no swap space created and that will prevent it from being added to the system swap mirror. You can then skip the entire process of stopping swap as it won't be an issue. If you go back to any drive you have already used and delete the swap partition on those drives, you won't have the problem with them either.

 

[Chris Moore]

When you export a pool from the GUI doesn't it disable the swap on the drives associated with that particular pool to allow safe removal?

It is a strange case because it is a single disk pool, but that is something that might need a bit of coding to fix. @wblock do you think this is a bug? Normally, when you export a pool, doesn't it take those drives out of swap use?

 

[M.A]

@Chris Moore

I would gladly share the zpool status but I'm off work now. Will do that tomorrow.

Thank you for sharing the tip about the swap settings. I'm aware of these settings but I didn't initially know it was the dangling swap partition that was causing the media not to eject. Also, if I set the swap value to Zero this will affect any future drives that get added to the system so I have to keep that in mind and also pass the tip to whomever is going to take care of that NAS later on. I'll consider it though. For now I have a trivial script that I can execute from the shell which ejects the drive for me.

The plan is for these drives to hold scheduled backups of the NAS and when they are filled up they will be removed to a safe storage and a new RDX media will be initialised and used and so on. There is a backup script in place that syncs the data from the main pool to the "backup" pool on the RDX media.

My main issue was the interruption that would have been caused if this media had to be ejected and, at the same time, users needed access to the NAS.

@cobrakiller58
A slight correction. I did not "export a pool from the GUI". I detached it. Still... you are right, the system should have taken care of the swap partition dismount. Perhaps this is an easy fix for the next update? :)

@wblock
I wouldn't touch the partitions on a backup drive. Maybe for the next one and before we copy data onto it. Better off wait until you guys fix this issue :D

 

[wblock]

It is a strange case because it is a single disk pool, but that is something that might need a bit of coding to fix. @wblock do you think this is a bug? Normally, when you export a pool, doesn't it take those drives out of swap use?

I don't know exactly what happens with single-disk pools meant for removal, and have not experimented with that. Does setting the swap partition size to zero actually not create a swap partition at all, or does it create a zero-sized one?

I wouldn't touch the partitions on a backup drive. Maybe for the next one and before we copy data onto it. Better off wait until you guys fix this issue :D

Did you enter a bug report for it? I'm not certain it's an issue, but a "Create this pool for use with external systems, do not create swap partitions" checkbox feature might be useful. For that matter, it would be useful to create a pool on an unpartitioned drive, which is what many systems will expect.

 

[Chris Moore]

The interesting lines for me were linea 11 & 12. So I dug a bit around the forum for "GEOM" messages and I found about the "gmirror" command. Reading the MAN/documentation I discovered I can use "gmirror status -ags" to list current status of active swaps. So I ran it in my second Terminal window and I got this

Since you have a solution, the following discussion is kind of academic and I hope it will provide additional information to someone at some time in the future.

At this time, July 2018, with Freenas version 11.1-U5, when I execute the gmirror status -ags command on my system that has 48 drives installed in it, I get the following output:

Code:

root@Emily-NAS:~/scripts # gmirror status -ags
	 swap0  COMPLETE  da35p1 (ACTIVE)
	 swap0  COMPLETE  da34p1 (ACTIVE)
swap0.sync	   N/A  N/A
	 swap1  COMPLETE  da33p1 (ACTIVE)
	 swap1  COMPLETE  da32p1 (ACTIVE)
swap1.sync	   N/A  N/A
	 swap2  COMPLETE  da31p1 (ACTIVE)
	 swap2  COMPLETE  da30p1 (ACTIVE)
swap2.sync	   N/A  N/A
	 swap3  COMPLETE  da29p1 (ACTIVE)
	 swap3  COMPLETE  da17p1 (ACTIVE)
swap3.sync	   N/A  N/A
	 swap4  COMPLETE  da16p1 (ACTIVE)
	 swap4  COMPLETE  da15p1 (ACTIVE)
swap4.sync	   N/A  N/A
root@Emily-NAS:~/scripts #

If you notice the da numbers, they are not consecutive and out of 48 drives, instead of having 24 mirrors, there are only 5.
It appears that FreeNAS is limited to having 5 of these mirrors in use for swap at any given time. What I have observed is that if one of these disks were to be removed, the associated mirror would remain degraded until the system is rebooted. My observation is that these mirrors are established at boot time. Some other users have reported that, in some instances, when a drive is added to the server, an incomplete mirror may be completed during the process that adds a new drive to a pool.

Does setting the swap partition size to zero actually not create a swap partition at all, or does it create a zero-sized one?

To test that, I looked at the results of glabel list for drives that have been added to my system over the course of several years while I had the swap partition size at various settings. First, some of the oldest drives in my system, that were added when I had the default value selected, have the following geometry:

Code:

Geom name: da20p1
Providers:
1. Name: gptid/ac6c9657-1c60-11e7-ae9a-002590a96034
   Mediasize: 2147483648 (2.0G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r0w0e0
   secoffset: 0
   offset: 0
   seclength: 4194304
   length: 2147483648
   index: 0
Consumers:
1. Name: da20p1
   Mediasize: 2147483648 (2.0G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r0w0e0

In this drive, partition 1 is a 2GB swap space.

Code:

Geom name: da20p2
Providers:
1. Name: gptid/ac988093-1c60-11e7-ae9a-002590a96034
   Mediasize: 4998830227456 (4.5T)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e1
   secoffset: 0
   offset: 0
   seclength: 9763340288
   length: 4998830227456
   index: 0
Consumers:
1. Name: da20p2
   Mediasize: 4998830227456 (4.5T)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e2

while partition 2 is a 4.5TB part of the backup storage pool.
Second, some of the more recent drives in my system, that were added when I had the value set to 1, have the following geometry:

Code:

Geom name: da1p1
Providers:
1. Name: gptid/d63d8a31-7d7e-11e8-b9c5-0cc47a9cd5a4
   Mediasize: 1073741824 (1.0G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r0w0e0
   secoffset: 0
   offset: 0
   seclength: 2097152
   length: 1073741824
   index: 0
Consumers:
1. Name: da1p1
   Mediasize: 1073741824 (1.0G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r0w0e0

In this drive, partition 1 is a 1GB swap space.

Code:

Geom name: da1p2
Providers:
1. Name: gptid/d64df9e0-7d7e-11e8-b9c5-0cc47a9cd5a4
   Mediasize: 98956410880 (92G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e1
   secoffset: 0
   offset: 0
   seclength: 193274240
   length: 98956410880
   index: 0
Consumers:
1. Name: da1p2
   Mediasize: 98956410880 (92G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e2

while partition 2 (on a SSD) is a 92GB part of another pool.
Third, even more recently, I added this one drive in my system, were I had the value set to 8, have the following geometry:

Code:

Geom name: da10p1
Providers:
1. Name: gptid/a3cc39d9-2a0a-11e8-bbf6-002590aecc79
   Mediasize: 8589934592 (8.0G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r0w0e0
   secoffset: 0
   offset: 0
   seclength: 16777216
   length: 8589934592
   index: 0
Consumers:
1. Name: da10p1
   Mediasize: 8589934592 (8.0G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r0w0e0

In this drive, partition 1 is a 8GB swap space because I was trying to have all my swap on this one drive. Trouble is, it didn't stay the 'selected' drive because the system appears to pick the drives it wants to use randomly at boot...

Code:

Geom name: da10p2
Providers:
1. Name: gptid/a41c596b-2a0a-11e8-bbf6-002590aecc79
   Mediasize: 991614861312 (924G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e1
   secoffset: 0
   offset: 0
   seclength: 1936747776
   length: 991614861312
   index: 0
Consumers:
1. Name: da10p2
   Mediasize: 991614861312 (924G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e2

while partition 2 is a 924GB (1TB drive) part of yet another pool.
Finally, the most recently added drives, were I had the value set to 0 (zero), have the following geometry:

Code:

Geom name: da22p1
Providers:
1. Name: gptid/194a8867-2a0b-11e8-bbf6-002590aecc79
   Mediasize: 500107771904 (466G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e1
   secoffset: 0
   offset: 0
   seclength: 976772992
   length: 500107771904
   index: 0
Consumers:
1. Name: da22p1
   Mediasize: 500107771904 (466G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e2

In this drive, partition 1 is a 466GB part of yet another pool and the interesting bit, there is not a partition 2...

 

[pro lamer]

the system appears to pick the drives it wants to use randomly at boot...

I can imagine a following scenario for my possible future needs:

1. Insert an RDX drive and let FreeNAS create a swap partition (so I have a spare space on the drive in case I replace it in future with a slightly smaller one (ie. 2TB <> 2 TB among various disks)
2. Cheat FreeNAS and change the type of the swap partition so FreeNAS doesn't select it ever as a mirror at boot
3. Result: I still have safety space
4. Cons: it might not be needed for write-once media

Other scenario, mentioned above:

1. Change swap size for new drives to 0 before inserting a blank new RDX drive so FreeNAS doesn't create a swap space there
2. Change the size back to 2 GB after the drive is initialized

 

[M.A]

@Chris Moore
Thank you for the expansion on the subject. Even though I solved the issue this is still interesting information for me nonetheless.

I went ahead and set the Swap partition size for new drives to Zero. I loaded a new RDX media and recreated the "backup" pool.

Here is my zpool status output with the original RDX media (before setting Swap = 0)

Code:

root@freenas:~ # zpool status
  pool: backup
 state: ONLINE
  scan: none requested
config:

NAME										  STATE	 READ WRITE CKSUM
backup										ONLINE	   0	 0	 0
  gptid/01f6613d-7ddd-11e8-b567-2cfda134680f  ONLINE	   0	 0	 0

errors: No known data errors
 
pool: freenas-boot
 state: ONLINE
  scan: none requested
config:

NAME		STATE	 READ WRITE CKSUM
freenas-boot  ONLINE	   0	 0	 0
  ada3p2	ONLINE	   0	 0	 0

errors: No known data errors

  pool: tank
 state: ONLINE
  scan: none requested

config:

NAME											STATE	 READ WRITE CKSUM
tank											ONLINE	   0	 0	 0
  raidz1-0									  ONLINE	   0	 0	 0
	gptid/03f5df53-7dc2-11e8-9fc0-2cfda134680f  ONLINE	   0	 0	 0
	gptid/04888a6a-7dc2-11e8-9fc0-2cfda134680f  ONLINE	   0	 0	 0
	gptid/0516df16-7dc2-11e8-9fc0-2cfda134680f  ONLINE	   0	 0	 0

errors: No known data errors

And here is the output afterwards

Code:

root@freenas:~ # zpool status

  pool: backup

 state: ONLINE

  scan: none requested

config:

NAME										  STATE	 READ WRITE CKSUM
backup										ONLINE	   0	 0	 0
  gptid/ea5e65a5-7f89-11e8-b1e9-2cfda134680f  ONLINE	   0	 0	 0

errors: No known data errors


  pool: freenas-boot
 state: ONLINE
  scan: none requested
config:

NAME		STATE	 READ WRITE CKSUM
freenas-boot  ONLINE	   0	 0	 0
  ada3p2	ONLINE	   0	 0	 0

errors: No known data errors

  pool: tank
 state: ONLINE
  scan: none requested
config:

NAME											STATE	 READ WRITE CKSUM
tank											ONLINE	   0	 0	 0
  raidz1-0									  ONLINE	   0	 0	 0
	gptid/03f5df53-7dc2-11e8-9fc0-2cfda134680f  ONLINE	   0	 0	 0
	gptid/04888a6a-7dc2-11e8-9fc0-2cfda134680f  ONLINE	   0	 0	 0
	gptid/0516df16-7dc2-11e8-9fc0-2cfda134680f  ONLINE	   0	 0	 0

errors: No known data errors

Now, with the Swap = 0, the output of gmirror status -ags looks like so

Code:

root@freenas:~ # gmirror status -ags
	swap0  COMPLETE  ada2p1 (ACTIVE)
	swap0  COMPLETE  ada1p1 (ACTIVE)
swap0.sync	   N/A  N/A

And the ejection of the RDX media requires only the camcontrol eject da0 -v command after detaching the RDX volume through the GUI.

Code:

root@freenas:~ # camcontrol eject da0 -v
Unit stopped successfully, Media ejected

So, Chris, your suggestion was right on the spot. Disabling Swap partition during the initialisation of a new RDX media should prevent this "I wont give you back your media until you reboot" issue until a fix or, as already suggested by @wblock , a "Create this pool for use with external systems, do not create swap partitions" checkbox feature is added to FreeNAS.

Thank you guys for your constructive input :)