Without the xfsdump output, it's hard to know exactly. However, xfsdump
will write out a file containing quota information to be included in the
dump -- assuming your filesystem has or had at some point, quotas
enabled.
Ivan
On Thu, 6 Jun 2002 11:03:38 +0200, Stephan Austermuehle wrote:
> Hi,
>
> I did the following:
>
> # xfs_freeze -f /usr
> # lvcreate -L 256m -n /dev/vg00/lv_usr_snap -s /dev/vg00/lv_usr
> # xfs_freeze -u /usr
> # mount -t xfs -o ro,nouuid /dev/vg00/lv_usr_snap /mnt
> # xfsdump -l 0 -p 60 - /mnt |buffer ... > /dev/nst1
>
> This results in the following error messages:
>
> XFS mounting filesystem lvm(58,19)
> lvm - lvm_map: ll_rw_blk write for readonly LV
> /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for
> readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write
> for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk
> write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map:
> ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm -
> lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap
> lvm - lvm_map: ll_rw_blk write for readonly LV
> /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for
> readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write
> for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk
> write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map:
> ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm -
> lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap
> lvm - lvm_map: ll_rw_blk write for readonly LV
> /dev/vg00/lv_usr_snap I/O error in filesystem ("lvm(58,19)")
> meta-data dev 0x3a13 block 0x1007fc
> ("xlog_iodone") error 5 buf count 6656
> xfs_force_shutdown(lvm(58,19),0x2) called from line 939 of file
> xfs_log.c. Return address = 0xc01bdbe6 Log I/O Error Detected.
> Shutting down filesystem: lvm(58,19) Please umount the
> filesystem, and rectify the problem(s) Unable to handle kernel
> NULL pointer dereference at virtual address 00000020
> printing eip:
> c0131f02
> *pde = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<c0131f02>] Not tainted
> EFLAGS: 00010202
> eax: 00003a13 ebx: 00000000 ecx: 00003a13 edx: 00003a13
> esi: 00000001 edi: 00000000 ebp: 00000000 esp: d01fdd60
> ds: 0018 es: 0018 ss: 0018
> Process lvremove (pid: 25437, stackpage=d01fd000)
> Stack: dfed8740 df466400 c0347df6 dfb6d000 3a13d000 00000000
> 00000000 c0132000
> dfed8740 00000000 dfe3b370 c0237668 00003a13 00000000
> 00003a13 00000000 bffff5ac c0347e64 dfb6d000 00000180
> dfb6d4c4 00000010 c0234c21 00000000
> Call Trace: [<c0132000>] [<c0237668>] [<c0234c21>] [<c01e2927>]
> [<c012581c>]
> [<c0125849>] [<c01b66cf>] [<c01ced1f>] [<c01b66cf>]
> [<c01ced1f>] [<c01391cf>] [<c013114e>] [<c01300f1>]
> [<c0130002>] [<c013cf89>] [<c0106e63>]
>
> Code: 8b 7b 20 0f b7 54 24 12 66 39 53 0c 0f 85 84 00 00 00 83
> 7b
>
> Why does xfsdump try to write to a filesystem that should be backup'd?
>
> Thanks for your help,
>
> Stephan
--
Ivan Rayner
ivanr@xxxxxxx
|