Using LVM on External Drive
 

I am using LVM on an External eSata drive that I take home on a nightly basis and am trying to find out what process I need to follow for removing the drive correctly and adding it back the next day without having to reboot the SAN it is connected to.

After reading the LVM how to's I am not sure if I should unmount or de-activate the Volume Group.

I see the vgchange -an and vgchange -a y but I am new to Linux and am not sure if that will make it OK to turn off and disconnect the drive. and it seems like when I bring it back the next day it is given the next drive letter (it is sdf on a boot and sdg when I reconnect it).

it is a single partition of 900GB and has a single share on it to hold copies of backup data to carry offsite.

Any help would be appreciated.

Unmount the (all) lvm-partitions then remove the drive. Now I don't really know about vgchange, but if you unmount all partitions you know it'll work.
I think - but I'm guessing now! - that vgchange only hides the logical volumes, not the drive in itself.
I believe the change in device-name is caused by the fact that the drive is not unmounted, so next time you connect it it gets the next drive letter.
Unmounting will prevent this.

Also, to avoid problems in the future, consider mounting with the "LABEL=" option or use "uuid".
(Can't give exakt examples out of my head, search a bit - if you don't find answers just return I'll help you further.)

A question: If the lvm consists of a single drive w a single partition with size 900GB, why lvm?

LVM on external
 

Well the distro I am using (Openfiler) uses LVM when it creates the Volume Groups and Shares. I used umount to unmount the partition and then went and tried to access the share and it was gone. Went and mounted it and I was able to access it again. I didn't disconnect the drive though. Since the partition is a LOGICAL volume and the sdf1 is a physical device isn't it the one that is picking up the sdg when I reconnect? but it tells me that /dev/sdf1 isn't mounted.

Since it shows that /dev/offsite/remotebkup is unmounted I will disconnect and see what happens when I return and reconnect tomorrow.

Well I reconnected and it showed up as sdg. So unmounting the Logical Volume didn't fix the problem. I had also tried unmounting the Physical Volume but it said that it wasn't mounted. Hummm..

Assuming the external drive has its own LVM volume group (not tested) ...

1. /bin/sync
2. Unmount the file systems in LVs provided by the VG on the external drive.
3. /sbin/vgchange -an --ignorelockingfailure <VGname>
   where <VGname> is, for example /dev/vg00

NOt yet.
 

Well I unmounted the LV and then tried to do the vgchange and I get

Can't deactivate volume group "offsite" with 1 open logical volume(s)

but running umount again it shows it as unmounted and when I try to access it I can't. Mount it back and I can access it. So I seem to be able to unmount and mount the LV (remotebkup) but can't take the VG (offsite) to inactive.

After playing with this for a few days. It can't be this hard to use an external eSATA drive for backups in linux.

Perhaps it would help to know which volume that is. Strange that one is still active despite none of them being mounted. There isn't any swap on the external drive is there?

The quick easy way than might work is /bin/ls -l /dev/mapper. Alternatively run lvs offsite. Any open volume will have an o for open as the last character in the Attr column. Alternatively run lvdisplay and look for LVs with a # open which is not 0.

No Luck
 

Well so far I have had Zero luck getting this to work smoothly and correctly. I do believe it might be me trying to make something do what it's not designed to do.

Most times I try to umount the LVM device I get a busy message and when I fuser it I get the PID and (Root) and it is usually smbd the Samba deamon running that keeps it from unmounting. The only way I have gotten it to unmount is by using a -l lazy unmount and still when I reconnect it picks up the next letter (was sdf, reconnects as sdg)and it doesn't see sdf or sdf1 as mounted. Being limited to using the Openfiler distro it seems using LVM is the only way Openfiler handles shares.

So anyone have any suggestions for how to handle the external eSata drive that needs to be removed nightly and returned the next day for daily copies from another Share on the SAN?

You could try the commands I suggested and post their output.

Results
 

Sorry..Here are the results

[root@SAN01 ~]# ls -l /dev/mapper
total 0
crw-rw---- 1 root root 10, 60 Mar 26 08:17 control
brw------- 1 root root 253, 0 Mar 26 08:17 offsite-remotebkup
brw------- 1 root root 253, 1 Mar 26 08:17 whse01-bkup01
brw------- 1 root root 253, 2 Mar 26 08:17 whse01-storage01
brw------- 1 root root 253, 3 Mar 26 08:17 whse01-vm01
brw------- 1 root root 253, 4 Mar 26 08:17 whse01-vmbkup
[root@SAN01 ~]#

[root@SAN01 ~]# lvs offsite
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
remotebkup offsite -wi-ao 900.00G

[root@SAN01 ~]# lvdisplay
--- Logical volume ---
LV Name /dev/offsite/remotebkup
VG Name offsite
LV UUID y3WySO-ATRT-ttKB-tDs2-pHao-Y1W3-8Rba1W
LV Write Access read/write
LV Status available
# open 1
LV Size 900.00 GB
Current LE 28800
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0

--- Logical volume ---
LV Name /dev/whse01/bkup01
VG Name whse01
LV UUID B1Xl3V-32wQ-8Wao-oupc-2gwJ-XJuE-4x9qM1
LV Write Access read/write
LV Status available
# open 1
LV Size 1.00 TB
Current LE 32768
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 768
Block device 253:1

--- Logical volume ---
LV Name /dev/whse01/storage01
VG Name whse01
LV UUID RsherC-pG6A-0s9z-RBFP-MA36-0Qjz-6cQDPJ
LV Write Access read/write
LV Status available
# open 1
LV Size 500.00 GB
Current LE 16000
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 768
Block device 253:2

--- Logical volume ---
LV Name /dev/whse01/vm01
VG Name whse01
LV UUID khEPoA-L23A-ZDEU-1UIo-PFeU-1xTS-8jGVlV
LV Write Access read/write
LV Status available
# open 1
LV Size 500.00 GB
Current LE 16000
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 768
Block device 253:3

--- Logical volume ---
LV Name /dev/whse01/vmbkup
VG Name whse01
LV UUID YsDh4p-6sSO-mWgK-EnH2-kI3C-joSb-2f1N02
LV Write Access read/write
LV Status available
# open 1
LV Size 500.00 GB
Current LE 16000
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 768
Block device 253:4


Ok, The other VG called whse01 is a Raid-5 group built from 4x1TB drives on it's own SATA Controller. The Offsite is on it's own Controller via eSata. And I just read where Openfiler uses the LVM for handling all of its Shares. I used the GUI to add the drive and set it up as an XFS filesystem and added the share to it.

I appreciate the help.

Other Messages
 

Here are some results from my attempts to do the umounts etc..

[root@SAN01 ~]# umount /dev/offsite/remotebkup
umount: /mnt/offsite/remotebkup: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))

[root@SAN01 ~]# fuser -vm /dev/offsite/remotebkup

USER PID ACCESS COMMAND
/dev/offsite/remotebkup
root 8206 ..c.. smbd

Oh and here is the vgdisplay also

[root@SAN01 ~]# vgdisplay
--- Volume group ---
VG Name offsite
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 931.50 GB
PE Size 32.00 MB
Total PE 29808
Alloc PE / Size 28800 / 900.00 GB
Free PE / Size 1008 / 31.50 GB
VG UUID 1HPAaH-ksy4-RfK0-hxy2-uRCH-zVln-Tg2XHq

--- Volume group ---
VG Name whse01
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 9
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 4
Open LV 4
Max PV 0
Cur PV 1
Act PV 1
VG Size 2.73 TB
PE Size 32.00 MB
Total PE 89425
Alloc PE / Size 80768 / 2.46 TB
Free PE / Size 8657 / 270.53 GB
VG UUID QcT6ZE-bx2s-pd5A-avjq-BRTq-o2cQ-0G4V0o

Hope this helps...

It helps a lot; it identifies the problem. The LV is still active because umount failed because smbd (Samba daemon) is running with a current working directory on the file system provided by the LV.

How are you starting smbd?

Samba
 

Well the Openfiler is a NAS/SAN distro so I believe that it is started by default at startup since the whole purpose is for sharing files across a network.

When I saw the smbd I did a lazy unmount using the -l and if I issue the command again it says it is unmounted. But it still won't let me do a vgchange -an saying that it has an active Volume...

Can you shut down SMBD on just a single volume? I'm sure my other shares on the Raid-5 need it to do thier nightly work while the offsite drive is home.

So far Openfiler has filled all the needs I was looking for except for this FAST eSata backup to a drive that can be carried offsite. Being able to copy 130 GB to an offsite drive in a few hours using eSATA vs USB 2.0 in 8+ hours is exactly what I have IF I can get the right mount/umount going without having to reboot each time.

Can we explore details? What is the root file system when Openfiler boots? What is the boot script mechanism? Somewhere in the detail of the boot scripts is the reason why smbd has an external file system for its current directory and potentially the workaround.

Boot Scripts
 

Well I could use a little help on some of this. Location,Name, etc. What am I looking for?

I read that Openfiler is pased on the rPath Linux Distro so am I looking for something in the /etc/rc.d/ rc.sysinit or lilo.config?