* [linux-lvm] EXT3 snapshot not quiesced by LVM2?
@ 2004-03-16 1:23 Donald Murray P.Eng.
2004-03-17 17:57 ` Donald Murray P.Eng.
2004-04-08 18:34 ` Donald Murray P.Eng.
0 siblings, 2 replies; 7+ messages in thread
From: Donald Murray P.Eng. @ 2004-03-16 1:23 UTC (permalink / raw)
To: linux-lvm
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] EXT3 snapshot not quiesced by LVM2?
2004-03-16 1:23 [linux-lvm] EXT3 snapshot not quiesced by LVM2? Donald Murray P.Eng.
@ 2004-03-17 17:57 ` Donald Murray P.Eng.
2004-03-17 18:12 ` Joe Thornber
2004-03-17 18:16 ` Steve Kann
2004-04-08 18:34 ` Donald Murray P.Eng.
1 sibling, 2 replies; 7+ messages in thread
From: Donald Murray P.Eng. @ 2004-03-17 17:57 UTC (permalink / raw)
To: linux-lvm
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] EXT3 snapshot not quiesced by LVM2?
2004-03-17 17:57 ` Donald Murray P.Eng.
@ 2004-03-17 18:12 ` Joe Thornber
2004-03-17 19:00 ` Donald Murray P.Eng.
2004-03-17 18:16 ` Steve Kann
1 sibling, 1 reply; 7+ messages in thread
From: Joe Thornber @ 2004-03-17 18:12 UTC (permalink / raw)
To: LVM general discussion and development
On Wed, Mar 17, 2004 at 10:57:25AM -0700, Donald Murray P.Eng. wrote:
> Does anyone have any theories why our LVM2 snapshots have orphaned inodes?
Yes, it's because the VFS lock patch isn't wired up correctly in the
version of dm that you're using - it's quiescing the wrong device.
You could try my _unstable_ dm tree if you wish to experiment.
people.sistina.com/~thornber/dm
- Joe
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] EXT3 snapshot not quiesced by LVM2?
2004-03-17 17:57 ` Donald Murray P.Eng.
2004-03-17 18:12 ` Joe Thornber
@ 2004-03-17 18:16 ` Steve Kann
1 sibling, 0 replies; 7+ messages in thread
From: Steve Kann @ 2004-03-17 18:16 UTC (permalink / raw)
To: LVM general discussion and development
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] EXT3 snapshot not quiesced by LVM2?
2004-03-17 18:12 ` Joe Thornber
@ 2004-03-17 19:00 ` Donald Murray P.Eng.
2004-03-17 22:06 ` Joe Thornber
0 siblings, 1 reply; 7+ messages in thread
From: Donald Murray P.Eng. @ 2004-03-17 19:00 UTC (permalink / raw)
To: LVM general discussion and development
We might take you up on that suggestion, Joe. Since we're using
2.4.22, that implies we should use the patches in:
http://people.sistina.com/~thornber/dm/patches/2.4-stable/2.4.22/2.4.22-dm-1/
Because we're using device-mapper 1.00.08, I'm assuming we need only
apply patches 9 through 16 to our already-patched kernel, correct?
I'll let the list know if this gets rid of the orphans.
On Wed, 17 Mar 2004 18:12:30 +0000
Joe Thornber <thornber@redhat.com> wrote:
> On Wed, Mar 17, 2004 at 10:57:25AM -0700, Donald Murray P.Eng. wrote:
> > Does anyone have any theories why our LVM2 snapshots have orphaned inodes?
>
> Yes, it's because the VFS lock patch isn't wired up correctly in the
> version of dm that you're using - it's quiescing the wrong device.
>
> You could try my _unstable_ dm tree if you wish to experiment.
>
> people.sistina.com/~thornber/dm
>
> - Joe
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] EXT3 snapshot not quiesced by LVM2?
2004-03-17 19:00 ` Donald Murray P.Eng.
@ 2004-03-17 22:06 ` Joe Thornber
0 siblings, 0 replies; 7+ messages in thread
From: Joe Thornber @ 2004-03-17 22:06 UTC (permalink / raw)
To: LVM general discussion and development
On Wed, Mar 17, 2004 at 12:00:56PM -0700, Donald Murray P.Eng. wrote:
> Because we're using device-mapper 1.00.08, I'm assuming we need only
> apply patches 9 through 16 to our already-patched kernel, correct?
No, apply them all, the patch numbers just signify application order.
- Joe
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] EXT3 snapshot not quiesced by LVM2?
2004-03-16 1:23 [linux-lvm] EXT3 snapshot not quiesced by LVM2? Donald Murray P.Eng.
2004-03-17 17:57 ` Donald Murray P.Eng.
@ 2004-04-08 18:34 ` Donald Murray P.Eng.
1 sibling, 0 replies; 7+ messages in thread
From: Donald Murray P.Eng. @ 2004-04-08 18:34 UTC (permalink / raw)
To: LVM general discussion and development
We've finally resolved this issue; it had nothing to do with LVM.
I tried upgrading to the LVM2 2.00.09 and device-mapper 1.00.09 but
still had occasional orphaned inodes when we mounted the snapshot. I
then tried the unstable patches from people.sistina.com/~thornber/dm;
this didn't fix the problem either.
I finally tried using lsof to see what was open on the origin logical
volume. This showed us that mysqld still had a log file open:
mysqld 1198 root 5w REG 254,1 2978 32771 /opt/data/mysql/mysqldb/slow.log.1 (deleted)
Because slow.log had been logrotated and compressed, the inode was in
fact an orphan. By adding 'mysqladmin flush-logs' to the postrotate section
of our mysql logrotate file, the problem went away.
We've now reverted back to LVM2 2.00.09 and device-mapper 1.00.09.
Thanks to Joe and Steve for your suggestions.
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-04-08 18:34 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-16 1:23 [linux-lvm] EXT3 snapshot not quiesced by LVM2? Donald Murray P.Eng.
2004-03-17 17:57 ` Donald Murray P.Eng.
2004-03-17 18:12 ` Joe Thornber
2004-03-17 19:00 ` Donald Murray P.Eng.
2004-03-17 22:06 ` Joe Thornber
2004-03-17 18:16 ` Steve Kann
2004-04-08 18:34 ` Donald Murray P.Eng.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox