この問題を解決できない場合は、システムのデフォルトに戻す必要がないかどうかを心配します。
より強力な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
不均一な行動は理解できません!私も興味深いです。2種類の行動の間には区切り線があります。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への今後のアップグレードを期待しています(もともと私はなぜこのすべてを掘り下げるのですか?)、インストールディスクが最新バージョンのカーネルやユーティリティではないため、違いを避けるには、次のように定義するプロセスに従う必要があります。
- 最新のオペレーティングシステムにアップグレードし、
- 再起動、
- すべてのアップデートを適用し、
- 現在ルートパーティションにあるアップグレードおよび更新されたオペレーティングシステムのバックアップイメージを作成します。
- 最新のカーネルとユーティリティ(セカンダリ内蔵ディスクにある完全に更新された冗長オペレーティングシステムを使用してください。、これが「プロダクション」に移動する前に必要な最終インストールをテスト、証明、検証するために500 GBのドライブが存在する理由です)、
- 完全に更新された基本オペレーティングシステムをバックアップイメージから正しい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
興味のある方のために修正/拡張されたスクリプトがあります。郵便。
皆様のご意見やフィードバックに感謝します。