이 문제를 해결하지 못하면 시스템 기본값으로 되돌려야 하지 않을까 걱정됩니다.
보다 강력한 ext4를 얻기 위해 다양한 시스템 구성을 설정하려고 합니다.단일 사용자 데스크탑 환경의 경우. 필수 구성 설정을 할당해 보세요.그들은 정상적으로 작동할 것입니다.
mke2fs.conf
나는 파일 시스템이 처음에 이러한 올바른 설정으로 생성되도록 이들 중 일부를 파일에 포함해야 한다는 것을 알고 있습니다 . 하지만 나중에 이를 수정하고 다음에 대한 배포 기본 파일을 유지하겠습니다.
내가 원하는 EXT4 옵션을 에서 사용할 수 있다는 것을 알고 있습니다 /etc/fstab
. 다음 항목은 내가 일반적으로 원하는 것을 보여줍니다.
UUID=00000000-0000-0000-0000-000000000000 /DB001_F2 ext4 defaults,nofail,data=journal,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,block_validity,nodelalloc,data_err=ignore,nodiscard 0 0
각각은DB001_F{p}
루트 디스크의 파티션입니다.( p = [2-8] ).
더 쉽게 이해할 수 있도록 목록과 동일한 순서로 옵션을 반복합니다.
defaults
nofail
data=journal
journal_checksum
journal_async_commit
commit=15
errors=remount-ro
journal_ioprio=2
block_validity
nodelalloc
data_err=ignore
nodiscard
부팅 중 설치 중에 다음 syslog에는 허용 가능한 설정으로 간주되는 모든 보고서가 표시됩니다.
64017 Sep 4 21:04:35 OasisMega1 kernel: [ 21.622599] EXT4-fs (sda7): mounted filesystem with journalled data mode. Opts: data=journal,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,block_validity,nodelalloc,data_err=ignore,nodiscard
64018 Sep 4 21:04:35 OasisMega1 kernel: [ 21.720338] EXT4-fs (sda4): mounted filesystem with journalled data mode. Opts: data=journal,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,block_validity,nodelalloc,data_err=ignore,nodiscard
64019 Sep 4 21:04:35 OasisMega1 kernel: [ 21.785653] EXT4-fs (sda8): mounted filesystem with journalled data mode. Opts: data=journal,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,block_validity,nodelalloc,data_err=ignore,nodiscard
64021 Sep 4 21:04:35 OasisMega1 kernel: [ 22.890168] EXT4-fs (sda12): mounted filesystem with journalled data mode. Opts: data=journal,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,block_validity,nodelalloc,data_err=ignore,nodiscard
64022 Sep 4 21:04:35 OasisMega1 kernel: [ 23.214507] EXT4-fs (sda9): mounted filesystem with journalled data mode. Opts: data=journal,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,block_validity,nodelalloc,data_err=ignore,nodiscard
64023 Sep 4 21:04:35 OasisMega1 kernel: [ 23.308922] EXT4-fs (sda13): mounted filesystem with journalled data mode. Opts: data=journal,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,block_validity,nodelalloc,data_err=ignore,nodiscard
64024 Sep 4 21:04:35 OasisMega1 kernel: [ 23.513804] EXT4-fs (sda14): mounted filesystem with journalled data mode. Opts: data=journal,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,block_validity,nodelalloc,data_err=ignore,nodiscard
그러나 mount
재부팅 후에도 일부 드라이브가 예상대로 보고되지 않는 것으로 나타났으며 이는 아래와 같이 일관성이 없습니다.
/dev/sda7 on /DB001_F2 type ext4 (rw,relatime,nodelalloc,journal_checksum,journal_async_commit,errors=remount-ro,commit=15,data=journal)
/dev/sda8 on /DB001_F3 type ext4 (rw,relatime,nodelalloc,journal_checksum,journal_async_commit,errors=remount-ro,commit=15,data=journal)
/dev/sda9 on /DB001_F4 type ext4 (rw,relatime,nodelalloc,journal_checksum,journal_async_commit,errors=remount-ro,commit=15,data=journal)
/dev/sda12 on /DB001_F5 type ext4 (rw,relatime,nodelalloc,journal_async_commit,errors=remount-ro,commit=15,data=journal)
/dev/sda13 on /DB001_F6 type ext4 (rw,relatime,nodelalloc,journal_async_commit,errors=remount-ro,commit=15,data=journal)
/dev/sda14 on /DB001_F7 type ext4 (rw,relatime,nodelalloc,journal_async_commit,errors=remount-ro,commit=15,data=journal)
/dev/sda4 on /DB001_F8 type ext4 (rw,relatime,nodelalloc,journal_async_commit,errors=remount-ro,commit=15,data=journal)
옵션 문자열의 길이 제한에 대한 내용을 어디선가 읽었기 때문에 일부 매개변수를 더 낮은 수준에서 미리 설정 fstab
하곤 했습니다 . tune2fs
다음을 통해 신청하는 경우 tune2fs
:
journal_data,block_validity,nodelalloc
사용 시 확인 tune2fs -l
:
Default mount options: journal_data user_xattr acl block_validity nodelalloc
fstab
일단 자리를 잡으면 다음과 같이 표시되도록 항목을 수정했습니다 .
UUID=00000000-0000-0000-0000-000000000000 /DB001_F2 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard 0 0
나는 umount
내 모든 DB001_F?
( )에 대해 /dev/sda*
다음을 수행 mount -av
하고 다음을 보고했습니다.
/ : ignored
/DB001_F2 : successfully mounted
/DB001_F3 : successfully mounted
/DB001_F4 : successfully mounted
/DB001_F5 : successfully mounted
/DB001_F6 : successfully mounted
/DB001_F7 : successfully mounted
/DB001_F8 : successfully mounted
각 드라이브의 옵션 문자열에서 오류가 보고되지 않았습니다.
사용해 보았지만 이 설정에서는 모두 실패했습니다 journal_checksum_v3
. 보고된 내용을 확인하기 위해 mount -av
이 명령을 사용합니다 .mount
또한 이러한 감소된 설정에 대해 재부팅하고 mount
작업을 다시 반복했는데 mount
드라이브가 예상대로 보고되지 않는 것으로 나타났으며 이는 아래와 같이 여전히 일관성이 없습니다.
/dev/sda7 on /DB001_F2 type ext4 (rw,relatime,journal_checksum,journal_async_commit,commit=15)
/dev/sda8 on /DB001_F3 type ext4 (rw,relatime,journal_checksum,journal_async_commit,commit=15)
/dev/sda9 on /DB001_F4 type ext4 (rw,relatime,journal_checksum,journal_async_commit,commit=15)
/dev/sda12 on /DB001_F5 type ext4 (rw,relatime,journal_async_commit,commit=15)
/dev/sda13 on /DB001_F6 type ext4 (rw,relatime,journal_async_commit,commit=15)
/dev/sda14 on /DB001_F7 type ext4 (rw,relatime,journal_async_commit,commit=15)
/dev/sda4 on /DB001_F8 type ext4 (rw,relatime,journal_async_commit,commit=15)
이는 ext4
유형 파일 시스템 이므로모두 동일한 물리적 드라이브에 있음, 이런 journal_checksum
불균일 한 행동이 이해가 안 돼요! 저도 흥미롭네요두 가지 유형의 행동 사이에는 구분선이 있습니다.fstab
, 위에 나열된 순서는 (에 따라)에 지정된 순서이므로 /DB001_F?
아마도 설치 순서일 것입니다. 그러면 나머지 설치 작업의 "다운그레이드"를 초래한 "글리치"는 무엇입니까?
내 생각(근거가 없을 수도 있다) 그게 다야파일 시스템을 생성할 때 일부 속성을 설정하는 것이 더 나을 수 있습니다., 이는 다른 것보다 더 "내구성/효과적"을 만들 것입니다. mke2fs.conf
. 을 전달하려고 하면 mke2fs.ext4
옵션 문자열의 길이가 제한되어 있기 때문에(64자?) 다시 실패하는 것 같습니다. 그래서...난 그걸 포기했어요 mke2fs.conf
.
mke2fs.conf
지금은 무시하세요fstab 및 une2fs 기능에 중점을 둡니다., 설치 시 현재 적용되는 전체 설정 범위가 올바르게 보고되지 않도록 내가 뭘 잘못하고 있는지 설명해줄 수 있나요?
현 시점에서는 ext4 동작의 실제 상태를 제공하기 위해 무엇을 신뢰할 수 있는지 모르겠고 단순히 배포 기본값으로 되돌리는 것을 고려하고 있습니다.
모든 것이 정상인데 시스템이 이를 올바르게 보고하지 않는 것이 가능합니까? 나는 이 관점을 편안하게 받아들일 수 있을지 모르겠습니다. 이것은 직관에 어긋납니다.
누구든지 도와줄 수 있나요?
환경
UbuntuMATE 20.04 LTS
Linux OasisMega1 5.4.0-124-generic #140-Ubuntu SMP Thu Aug 4 02:23:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
RAM = 4GB
DSK = 2TB (internal, 8 data partitions, 3 1GB swap partitions) [ROOT]
DSK = 500GB (internal, 2 data partitions, 1 1GB swap partitions)
DSK = 4TB (external USB, 16 data partitions) [BACKUP drive]
아래에 보고된 내용은 다음과 같습니다 debugfs
.
Filesystem features:
has_journal
ext_attr
resize_inode
dir_index
filetype
needs_recovery
extent
flex_bg
sparse_super
large_file
huge_file
dir_nlink
extra_isize
metadata_csum
문제를 더 깊이 이해하는 데는 별로 유용하지 않습니다.
debugfs
다음을 표시합니다지원됨특징:
debugfs 1.45.5 (07-Jan-2020)
Supported features: (...snip...) journal_checksum_v2 journal_checksum_v3
or available 이 debugfs
표시되지만 매뉴얼 페이지에서 참조되는 것은 아니라는 점에 주목할 가치가 있습니다 .journal_checksum_v2
journal_checksum_v3
journal_checksum
이는 대신 v2
or 을 사용해야 한다는 뜻입니까 ?v3
journal_checksum
답변1
내 원래 게시물에 대한 댓글에서 발생한 논의를 고려하여 다음과 같은 결론을 내릴 준비가 되었습니다.처음 설치한 후 2년이 넘도록 커널에 많은 변경이 있었습니다.UbuntuMATE 20.04 LTS 릴리스의 8개 버전에서 관찰된 동작 차이의 출처외부 4 파일 시스템같은 육체를 갖고 있지만 창조된 시기는 다르다장비.
따라서 모든 파일 시스템이 제공되도록 보장하는 유일한 방법은파일 시스템 유형(즉외부 4)는 설치 옵션과 동일한 방식으로 반응합니다.2fs 조정옵션과 동작/보고가 동일합니다.2fs 디버깅또는산보장하기 위해운영 체제 커널과 다양한 파일 시스템 유틸리티의 동일한 고정 버전을 사용하여 생성됩니다.이러한 파일 시스템을 생성하고 조정하는 데 사용됩니다.
그래서 내 원래 질문에 답하기 위해,파일 시스템에서 다른 문제가 보고됨그들의 보고는 정확하기 때문에 각자는 자신의 이야기를 이끌어낸 역사적 배경을 가지고 있습니다.현재 상태.
UbuntuMATE 22.04 LTS로의 향후 업그레이드를 기대합니다(애초에 내가 왜 이 모든 것을 파고드는 걸까?), 설치 디스크가 최신 버전의 커널이나 유틸리티가 아니기 때문에 차이점을 방지하려면 다음과 같이 정의하는 프로세스를 따라야 합니다.
- 최신 운영 체제로 업그레이드하고,
- 재시작,
- 모든 업데이트를 적용하고,
- 현재 루트 파티션에 있는 업그레이드 및 업데이트된 운영 체제의 백업 이미지를 생성합니다.
- 최신 커널과 유틸리티(보조 내부 디스크에 있는 완전히 업데이트된 중복 운영 체제를 사용하세요., 이것이 바로 "프로덕션"으로 이동하기 전에 필요한 최종 설치를 테스트, 증명, 검증하기 위해 내 500GB 드라이브가 존재하는 이유입니다),
- 완전히 업데이트된 기본 운영 체제를 백업 이미지에서 올바른 ROOT 파티션으로 복원합니다.
- 재부팅한 다음
- 기본 디스크의 다른 모든 파티션을 백업하고 다시 만든 다음 각 파티션의 데이터를 복원합니다.
그래야만 모든 파티션을 "동일"로 생성할 수 있습니다.최신의 최고의 스냅샷을 적시에 제공합니다. 그렇지 않으면 루트 파티션은 배포판을 설치하고 업데이트한 후에 생성된 다른 모든 파티션과 일치하지 않게 됩니다.
또한 내가 만든 것과 비슷한 스크립트를 사용하면 필요한 작업이 균일하게 적용되므로 수동으로 여러 번 수행할 때 발생할 수 있는 지루한 실수를 피할 수 있습니다.
스크립트를 사용하여 이러한 옵션을 일관된 방식으로 관리하고 볼 수 있기를 원하는 사람들을 위해 제가 직접 만든 스크립트는 다음과 같습니다.
#!/bin/sh
####################################################################################
###
### $Id: tuneFS.sh,v 1.2 2022/09/07 01:43:18 root Exp $
###
### Script to set consistent (local/site) preferences for filesystem treatment at boot-time or mounting
###
####################################################################################
TIMESTAMP=`date '+%Y%m%d-%H%M%S' `
BASE=`basename "$0" ".sh" `
###
### These variables will document hard-coded 'mount' preferences for filesystems
###
BOOT_MAX_INTERVAL="-c 10" ### max number of boots before fsck [10 boots]
TIME_MAX_INTERVAL="-i 2w" ### max calendar time between boots before fsck [2 weeks]
ERROR_ACTION="-e remount-ro" ### what to do if error encountered
#-m reserved-blocks-percentage
###
### This OPTIONS string should be updated manually to document
### the preferred and expected settings to be applied to ext4 filesystems
###
OPTIONS="-o journal_data,block_validity,nodelalloc"
ASSIGN=0
REPORT=0
VERB=0
SINGLE=0
while [ $# -gt 0 ]
do
case ${1} in
--default ) REPORT=0 ; ASSIGN=0 ; shift ;;
--report ) REPORT=1 ; ASSIGN=0 ; shift ;;
--force ) REPORT=0 ; ASSIGN=1 ; shift ;;
--verbose ) VERB=1 ; shift ;;
--single ) SINGLE=1 ; shift ;;
* ) echo "\n\t Invalid parameter used on the command line. Valid options: [ --default | --report | --force | --single | --verbose ] \n Bye!\n" ; exit 1 ;;
esac
done
workhorse()
{
case ${PARTITION} in
1 )
DEVICE="/dev/sda3"
OPTIONS=""
;;
2 )
DEVICE="/dev/sda7"
;;
3 )
DEVICE="/dev/sda8"
;;
4 )
DEVICE="/dev/sda9"
;;
5 )
DEVICE="/dev/sda12"
;;
6 )
#UUID="0d416936-e091-49a7-9133-b8137d327ce0"
#DEVICE="UUID=${UUID}"
DEVICE="/dev/sda13"
;;
7 )
DEVICE="/dev/sda14"
;;
8 )
DEVICE="/dev/sda4"
;;
esac
PARTITION="DB001_F${PARTITION}"
PREF="${BASE}.previous.${PARTITION}"
reference=`ls -t1 "${PREF}."*".dumpe2fs" 2>/dev/null | grep -v 'ERR.dumpe2fs'| tail -1 `
if [ ! -s "${PREF}.dumpe2fs.REFERENCE" ]
then
mv -v ${reference} ${PREF}.dumpe2fs.REFERENCE
fi
reference=`ls -t1 "${PREF}."*".verify" 2>/dev/null | grep -v 'ERR.verify'| tail -1 `
if [ ! -s "${PREF}.verify.REFERENCE" ]
then
mv -v ${reference} ${PREF}.verify.REFERENCE
fi
BACKUP="${BASE}.previous.${PARTITION}.${TIMESTAMP}"
BACKUP="${BASE}.previous.${PARTITION}.${TIMESTAMP}"
rm -f ${PREF}.*.tune2fs
rm -f ${PREF}.*.dumpe2fs
### reporting by 'tune2fs -l' is a subset of that from 'dumpe2fs -h'
if [ ${REPORT} -eq 1 ]
then
### No need to generate report from tune2fs for this mode.
( dumpe2fs -h ${DEVICE} 2>&1 ) | awk '{
if( NR == 1 ){ print $0 } ;
if( index($0,"revision") != 0 ){ print $0 } ;
if( index($0,"mount options") != 0 ){ print $0 } ;
if( index($0,"features") != 0 ){ print $0 } ;
if( index($0,"Filesystem flags") != 0 ){ print $0 } ;
if( index($0,"directory hash") != 0 ){ print $0 } ;
}'>${BACKUP}.dumpe2fs
echo "\n dumpe2fs REPORT [$PARTITION]:"
cat ${BACKUP}.dumpe2fs
else
### Generate report from tune2fs for this mode but only as sanity check.
tune2fs -l ${DEVICE} 2>&1 >${BACKUP}.tune2fs
( dumpe2fs -h ${DEVICE} 2>&1 ) >${BACKUP}.dumpe2fs
if [ ${VERB} -eq 1 ] ; then
echo "\n tune2fs REPORT:"
cat ${BACKUP}.tune2fs
echo "\n dumpe2fs REPORT:"
cat ${BACKUP}.dumpe2fs
fi
if [ ${ASSIGN} -eq 1 ]
then
tune2fs ${BOOT_MAX_INTERVAL} ${TIME_MAX_INTERVAL} ${ERROR_ACTION} ${OPTIONS} ${DEVICE}
rm -f ${PREF}.*.verify
( dumpe2fs -h ${DEVICE} 2>&1 ) >${BACKUP}.verify
if [ ${VERB} -eq 1 ] ; then
echo "\n Changes:"
diff ${BACKUP}.dumpe2fs ${BACKUP}.verify
fi
else
if [ ${VERB} -eq 1 ] ; then
echo "\n Differences:"
diff ${BACKUP}.tune2fs ${BACKUP}.dumpe2fs
fi
rm -f ${BACKUP}.verify
fi
fi
}
if [ ${SINGLE} -eq 1 ]
then
for PARTITION in 2 3 4 5 6 7 8
do
echo "\n\t Actions only for DB001_F${PARTITION} ? [y|N] => \c" ; read sel
if [ -z "${sel}" ] ; then sel="N" ; fi
case ${sel} in
y* | Y* ) DOIT=1 ; break ;;
* ) DOIT=0 ;;
esac
done
if [ ${DOIT} -eq 1 ]
then
workhorse
fi
else
for PARTITION in 2 3 4 5 6 7 8
do
workhorse
done
fi
exit 0
exit 0
exit 0
관심 있는 분들을 위해 수정/확장된 스크립트가 있습니다.우편.
여러분의 의견과 피드백에 감사드립니다.