NFS 서버가 EXT4 시스템 디스크에 "잘못된 범위"를 생성합니까?

NFS 서버가 EXT4 시스템 디스크에 "잘못된 범위"를 생성합니까?

dom0과 4개의 domU 각각에 Oneiric이 포함된 Xen 4.1을 실행하는 서버가 있습니다. domU의 시스템 디스크는 mdadm RAID1 위에 구축된 LVM2 볼륨입니다.

모든 domU 시스템 디스크는 EXT4이며 동일한 원본 템플릿의 스냅샷을 사용하여 생성됩니다. 그 중 3개는 완벽하게 실행되지만 하나(s-ub-02라고 함)는 읽기 전용으로 계속 다시 마운트됩니다. 후속 e2fsck결과는 단일 "잘못된 범위" 진단으로 이어집니다.

e2fsck 1.41.14 (22-Dec-2010)
/dev/domu/s-ub-02-root contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 525418 has an invalid extent
    (logical block 8959, invalid physical block 0, len 0)
Clear<y>? yes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/domu/s-ub-02-root: 77757/655360 files (0.3% non-contiguous), 360592/2621440 blocks

콘솔에는 일반적으로 시스템 디스크(xvda2)에 대해 다음과 같은 오류가 표시됩니다.

[101980.903416] EXT4-fs error (device xvda2): ext4_ext_find_extent:732: inode #525418: comm apt-get: bad header/extent: invalid extent entries - magic f30a, entries 12, max 340(340), depth 0(0)
[101980.903473] EXT4-fs (xvda2): Remounting filesystem read-only

시스템 디스크의 새 버전을 만들었습니다. 항상 같은 일이 일어납니다. 이 점과 디스크가 궁극적으로 RAID1에 있다는 사실로 인해 하드웨어 디스크 오류가 발생하지 않을 수 있습니다.

이 domU의 유일한 명백한 구별 특징은 의 존재 nfs-kernel-server이므로 나는 그렇게 생각합니다. 파일 은 exports다음과 같습니다:

/exports/users           192.168.0.0/255.255.248.0(rw,sync,no_subtree_check)
/exports/media/music     192.168.0.0/255.255.248.0(rw,sync,no_subtree_check)
/exports/media/pictures  192.168.0.0/255.255.248.0(rw,sync,no_subtree_check)
/exports/opt             192.168.0.0/255.255.248.0(rw,sync,no_subtree_check)

/exports/users/exports/opt시스템 디스크와 동일한 볼륨 그룹의 LVM2 볼륨입니다 . /exports/mediaEXT2 볼륨입니다. (클라이언트가 /exports/media/pictures읽기 전용 볼륨으로 간주 하는 문제가 있는데 , 완전성을 위해 언급합니다.)

읽기 전용 문제를 제외하고 NFS 서버는 "잘못된 범위" 문제가 발생하기 전 몇 시간 동안 가벼운 로드 하에서 올바르게 작동하는 것으로 보입니다.

에는 유용한 항목이 없습니다 /var/log. 갑자기 더 이상 파일이 기록되지 않으므로 디스크가 읽기 전용으로 다시 마운트된 시기를 알 수 있지만 원인이 무엇인지 알 수는 없습니다.

누구든지 이 문제를 해결하도록 도와줄 수 있나요?

스티브

답변1

이 문제는 OP로 해결되었습니다.

마침내 ext4를 버리고 ext4가 다시 재생되기 시작한 후 ext3으로 돌아가서 이 문제를 해결했습니다. 특정 VM에 뭔가 이상한 일이 벌어지고 있지만 그것이 무엇인지 알아내려고 더 이상 시간을 보낼 수 없습니다.

관련 정보