[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [linux-lvm] EXT3 snapshot not quiesced by LVM2?




I figured someone would chime in here with a better explanation.

The orphaned inodes do not indicate that the filesystem is in an inconsistent state.  It is "in use", yes, but not inconsistent.

Unix semantics allow processes to keep open a handle to a file which is no longer referenced by any directories.  The file must still exist on the filesystem, although there's no way to access it other than the file descriptor held by the process.

This is a common practice for scratch files;   open a new file (O_CREAT), unlink the file, use the file.

When the last process referencing the file goes away, the kernel normally will remove the file from the filesystem.  In this way, a process doesn't need to worry about clean-up, and clean-up works properly in the case that the process dies unexpectedly.

So, anyway, the issue you're seeing doesn't seem to be an error of any kind.



Donald Murray P.Eng. wrote:
Does anyone have any theories why our LVM2 snapshots have orphaned inodes?


On Mon, 15 Mar 2004 18:23:56 -0700
"Donald Murray P.Eng." <donald murray pason com> wrote:

  
Problem:
LVM2 snapshots of an EXT3 partition do not appear to be taken
from a quiesced lv. In /var/log/messages, we see messages about
an orphaned inode.

Details:
We're using LVM2 on a RedHat 7.2 box with a 2.4.22 kernel from kernel.org.
The kernel has been patched with the following patches:
    linux-2.4.22-VFS-lock.patch
    linux-2.4.22-devmapper-ioctl.patch

Once per hour, we use an LVM snapshot to backup a MySQL database. The
procedure is:
1. mysql server: flush tables with read lock; hold this lock until step 5
2. sync
3. lvcreate --extents N --snapshot --name dbsnapshotlv /dev/datavg/datalv
4. mount -o ro /dev/datavg/dbsnapshotlv /mnt/snapshot
5. mysql server: unlock tables
6. create backup of /mnt/snapshot
7. umount /mnt/snapshot && lvremove /dev/datavg/dbsnapshotlv

This appears to be working, but there is a message in /var/log/messages
which is a little disturbing. Whenever we create a snapshot and mount
the resulting lv, we see the following:

Mar 15 05:00:05 PC kernel: EXT3-fs: INFO: recovery required on readonly filesystem.
Mar 15 05:00:05 PC kernel: EXT3-fs: write access will be enabled during recovery.
Mar 15 05:00:05 PC kernel: kjournald starting.  Commit interval 5 seconds
Mar 15 05:00:05 PC kernel: EXT3-fs: device-mapper(254,4): orphan cleanup on readonly fs
Mar 15 05:00:05 PC kernel: EXT3-fs: device-mapper(254,4): 1 orphan inode deleted
Mar 15 05:00:05 PC kernel: EXT3-fs: recovery complete.
Mar 15 05:00:05 PC kernel: EXT3-fs: mounted filesystem with ordered data mode.
...
Mar 15 06:00:05 PC kernel: EXT3-fs: INFO: recovery required on readonly filesystem.
Mar 15 06:00:05 PC kernel: EXT3-fs: write access will be enabled during recovery.
Mar 15 06:00:07 PC kernel: kjournald starting.  Commit interval 5 seconds
Mar 15 06:00:07 PC kernel: EXT3-fs: device-mapper(254,4): orphan cleanup on readonly fs
Mar 15 06:00:07 PC kernel: EXT3-fs: device-mapper(254,4): 1 orphan inode deleted
Mar 15 06:00:07 PC kernel: EXT3-fs: recovery complete.
Mar 15 06:00:07 PC kernel: EXT3-fs: mounted filesystem with ordered data mode.
...
Mar 16 01:00:06 PC kernel: EXT3-fs: INFO: recovery required on readonly filesystem.
Mar 16 01:00:06 PC kernel: EXT3-fs: write access will be enabled during recovery.
Mar 16 01:00:08 PC kernel: kjournald starting.  Commit interval 5 seconds
Mar 16 01:00:08 PC kernel: EXT3-fs: device-mapper(254,4): orphan cleanup on readonly fs
Mar 16 01:00:08 PC kernel: EXT3-fs: device-mapper(254,4): 1 orphan inode deleted
Mar 16 01:00:08 PC kernel: EXT3-fs: recovery complete.
Mar 16 01:00:08 PC kernel: EXT3-fs: mounted filesystem with ordered data mode.


When we mount the snapshot read-write, we instead see the following:

Mar 16 01:09:17 PC kernel: kjournald starting.  Commit interval 5 seconds
Mar 16 01:09:17 PC kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on device-mapper(254,4), internal journal
Mar 16 01:09:17 PC kernel: EXT3-fs: device-mapper(254,4): 1 orphan inode deleted
Mar 16 01:09:17 PC kernel: EXT3-fs: recovery complete.
Mar 16 01:09:17 PC kernel: EXT3-fs: mounted filesystem with ordered data mode.


All we expected to see in /var/log/messages was something more like:

Mar 17 01:09:03 PC kernel: kjournald starting.  Commit interval 5 seconds
Mar 17 01:09:03 PC kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on device-mapper(254,4), internal journal
Mar 17 01:09:03 PC kernel: EXT3-fs: mounted filesystem with ordered data mode.


Why would the snapshot volume have an orphaned inode? Doesn't the VFS patch
allow us to snapshot EXT3? Do we need to quiesce the origin lv some other
way?



 ------------------------------------------ 
 Donald Murray, P.Eng.
 Senior Software Engineer
 Pason Systems Corp.
 Direct: (403) 301-3473

_______________________________________________
linux-lvm mailing list
linux-lvm redhat com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
    


 ------------------------------------------ 
 Donald Murray, P.Eng.
 Senior Software Engineer
 Pason Systems Corp.
 Direct: (403) 301-3473

_______________________________________________
linux-lvm mailing list
linux-lvm redhat com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

  


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]