2

Not sure if it's better suited for superuser of unix&linux boards, let me know.

We have a server which is one of the main key points of a somehow large architecture. This server has a backup disk which was not used, although it hosted very old backups. So I decided to set it up, and while it was at the beginning a single partition I used fdisk to repartition it the same way as the primary drive (both are identical).

Unfortunately, after the repartitionning fdisk couldn't manage to get the kernel see the new partition table, nor could partrobe, blockdev or sfdisk. All faced the same issue : BLKRRPART: Device or resource busy, though neither lsof nor fuser did show anything using the device. Here I have to mention that I used umount -l to force the unmount before using fdisk (yes, now it seems stupid and I should have read the doc more carefully).

Afterwards I figured out NFS was sharing one of the directory of the drive, which is why it didn't appear in lsof and fuser — don't ask me who had the silly idea of using a directory from an old backup drive to share startup configuration files for NFS clients…

I can't reboot this server, and I won't restart NFS. I've read I could use nfs-kernel-server reload to keep NFS transfers while reloading /etc/exports (if I understood correctly), but first I'm not sure this will work and second I really don't want to try that. I really want to avoid interfering with running processes.

Now, if the directory indeed appears in the output of showmount -e (which seems basically the same as /etc/exports), it appears neither in showmount -a nor in showmount -d. I guess this means the directory is not in used, so maybe there is some way to force the unmount from NFS ?

Any suggestions ?

Skippy le Grand Gourou
  • 1,145
  • 14
  • 23

1 Answers1

1

NFSv2 and NFSv3 are stateless protocols. This means that, particularly when using UDP, you can restart the server with no effect whatsoever on connected clients.

I've read I could use nfs-kernel-server reload to keep NFS transfers while reloading /etc/exports (if I understood correctly), but first I'm not sure this will work and second I really don't want to try that.

If you're not going to trust what you read, it's hard to give suggestions. Editing /etc/exports and running nfs-kernel-server reload is of course the right solution. Running this simply executes exportfs -r, which is the correct way to update the exports of a running server without restarting it.

As an aside, you said:

I have to mention that I used umount -l to force the unmount before using fdisk

To clarify, umount -l does not force an unmount. It's possible that your filesystem is still mounted, or was still mounted while you ran fdisk.

Jim Paris
  • 276
  • 2
  • 3
  • 8
  • It's not that I don't trust what I read (though it depends of course on where I read it). It's rather that I want to be sure I understand what I read, especially when dealing with such sensitive things (and especially when not following this advice has just lead me to trouble, as you've seen with `umount -l` — though then it was supposed to be only an old unused backup drive so in principle it would have been harmless to just wipe everything out from it or to break its filesystem). – Skippy le Grand Gourou Nov 07 '12 at 22:38
  • I'm quite reassured by your answer concerning NFS. This is probably the way to go indeed. – Skippy le Grand Gourou Nov 07 '12 at 22:39
  • Better late than never : ``nfs-kernel-server`` not existing in the server (Scientific Linux 4.5 Beryllium), I used directly ``exportfs -r``, which did not seem to break the system. Afterwards I was able to unmount the partitions correctly and to proceed with writing the partition table – though ``showmount -e`` still shows the old layout. Thanks. – Skippy le Grand Gourou Dec 10 '12 at 14:52