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

[Steve Kann <stevek@stevek.com>]

[-- Attachment #1: Type: text/plain, Size: 5543 bytes --]


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/
>
>  
>


[-- Attachment #2: Type: text/html, Size: 6421 bytes --]