Yeah, the NAS version is 5.5.27-5.

If I reboot the data mover, will it affect all the fileystems? So, do I have to reboot it during a downtime?

yes, affects all file system

whether you need downtime or not depends on your application - I would certainly at least choose a quiet time.

before doing that I would try rebooting the Controlstation, which doesnt affect client traffic.
Just on the chance that something on the CS holds that file system busy

The DM definitely still thinks the filesystem is in use by something. Is it being used by Replication, DHSM (Filemover), or any other feature? Is there a filesystem mounted in a path underneath that path (i.e. you have something mounted at /test1/sub1)?

Otherwise, are you running versions 5.5.27 through 5.5.30? And if so, have you ever run the server_checkup command against this DM since it was last rebooted?

There was a bug identified (will be fixed in 5.5.31 due out later this month) in server_checkup that will intermittently result in filesystems being marked "in use" and make them unable to be unmounted. If this is your problem, unfortunately the only resolution is to perform a DM failover or reboot.

Right, all filesystems owned by the DM will be unavailable until the reboot or failover is complete (failover is much faster and the amount of time depends on the size of your configuration, but both nearly always complete in "minutes", i.e. a minute or more, but less than 10).

Most people would schedule a downtime for it, unless you know that your environment won't have a production impact by reboot/failover (some don't).

That'd usually be the way, though it will let you unmount even if there are still NFS or CIFS exports (in case you just wanted to unmount temporarily and re-mount with different options, without making you remove all the exports you'd set up).

You'd also need to re-configure any services that were configured to use that filesystem (like Celerra Replicator, DHSM (filemover), iSCSI, etc.) to not use the FS anymore. Normally it will tell you if one of these services is in use, and that's why it can't be unmounted, though.

No, the reboot command on the CS will reboot the control station. It's the data mover that has the problem and needs to be rebooted in this case, with either:

server_cpu (for rebooting)
server_standby (for failing over/back)
Or the equivalents from the GUI.

If the server_checkup command has never been run on this system, though, then rebooting/failing over may not change anything. If it does, though, you'd want to make sure that you eventually upgrade to 5.5.31 or higher to avoid this problem happening again (or don't use server_checkup).

Just run the reboot command on the CS right?

Is there an order of removing the filesystem?

For example, do you remove the checkpoints for the filesystem first, then remove nfs exports, and/or cifs exports, and then umount the filesystem, lastly removing the filesystem?

yes - as simple as that

Shouldn't be pretty simple, but will require a little downtime, and you'll need to coordinate with your local EMC support team (currently upgrades still need to be performed by EMC).

Sorry, I meant to say "It should be pretty simple".

This is what happens when I proofread and edit my message, but don't proofread it again!

I've seen this happening twice on the filesystems. I've followed the correct order to remove it and it ends with the same issue.

how difficult is to upgrade it to 5.5.31?

I'll prefer to engage NAS Support on this issue and let them troubleshoot and identify the root cause. If required, they will suggest a NAS code upgrade or Patch upgrade and send the request to EMC CE for doing the upgrade.

However, the with-in family code upgrade may be an Online one - but you need to reboot the data mover sometime (either during the upgrade or after the upgrade) in order to make the new code effective.

By the way, there is no harm in rebooting the control station once as suggested by Rainer and try the same.

Lastly, I don't think 5.5.31 is available to field yet.

My 2 cents

Thanks,
Sandip

Sandip has a very good point. I don't want to discourage anyone from doing proactive upgrades to fix known issues, but it's definitely in your best interest to work with support to identify the root cause of the problem you're having. Right now we're really just guessing that the problem you're seeing is the one that I mentioned.

Second, a footnote I should have added - like any bugfix that hasn't been released, there's always a possibility things may change. The fix I mentioned is scheduled to be included in 5.5.31, but until it's officially released there's a possibility that this may change. It's always best to work with Support on potential fixes and the releases they're available in.

Hi nasgurunot,

can you let us know if rebooting the ControlStation helped ?

The other thing I can think of if you have ISCSI enabled on that file system - I think if there still are ISCSI LUNs configured there it also wouldnt let you remove it before you delete these ISCSI LUNs