Ext4 파일 시스템에 대해 조금 배우고 있습니다.여기. 이 링크의 첫 번째 테이블에서는 인덱스 노드의 필드를 설명합니다. 각 필드 항목에는 다음이 하나씩 있습니다.
오프셋
크기
이름
설명하다
설명 필드에서 문서에는 이러한 값 중 일부가 낮거나 높다고 명시되어 있습니다. 낮은/높은 비트는 무엇을 의미하며, 이 ext4 파일 시스템 예제에서 해당 개념을 사용하는 이유는 무엇입니까?
답변1
사용하여 예를 들어 보겠습니다.문서귀하의 질문에 링크한 참고 사항: i_uid필드의 크기 __le16는 으로 설명됩니다 Lower 16-bits of Owner UID. 이 파일 시스템이 생성된 시스템이 16비트 사용자 ID만 허용하는 경우 모든 사용자 ID를 이 i_uid필드에 입력할 수 있습니다. __le16실제로 "리틀 엔디안 16비트"가 표시됩니다. 비유하자면, 두 자리 숫자만 가질 수 있고 비용이 29달러라면 그것이 맞을 것이기 때문에 설정될 것입니다.
32비트 사용자 ID를 사용하는 경우(더 큰 사용자 ID를 사용하는 시스템은 없다고 확신합니다) 32비트 사용자 ID는 크기 필드에 맞지 않으므로 __le1632비트는 두 개의 16비트로 분할됩니다. 비트 수량. 0(최하위 비트)부터 31(최상위 비트)까지 비트 번호를 매기면(명확하게 설명하기 위한 관례일 뿐입니다) 비트 0-15("하위" 비트)가 여기에 배치됩니다. i_uid필드이지만 비트 16-31("상위" 비트)은 맞지 않으므로 다른 곳으로 이동해야 합니다. 32비트 사용자 ID를 사용하는 Linux에서는 l_i_uid_highinode 필드의 하위 필드로 끝납니다. osd2비유하자면, 비용이 129달러인데 두 자리 상자가 있는 경우 29아래쪽 두 자리 상자에 들어가고 01위쪽 두 자리 상자에 들어갑니다.
몇 가지 추가 참고 사항: 모든 필드는 "리틀 엔디안"입니다. 필드가 1바이트 이상으로 구성된 경우(예: __le162바이트로 구성) 최하위 바이트가 먼저, 최상위 바이트가 먼저 순서는 두 번째이지만 순서는 다음과 같습니다. 인접한. 그건에도 불구하고시스템 CPU의 엔디안: 이렇게 하면 파일 시스템이 디스크에 배치되는 방식이 CPU와 무관하게 원하는 경우 다른 시스템에서 이 파일 시스템을 역바이트 순서로 읽을 수 있습니다. 예, 두 시스템에서 실행되는 ext4 버전은 호환되어야 합니다.
또한 사용자 ID의 하위 16비트(= 2바이트)와 사용자 ID의 상위 16비트는 디스크의 두 위치에 저장됩니다.아니요인접: 첫 번째는 inode 시작에서 오프셋 0x2에 있지만 두 번째는 inode 시작에서 오프셋 0x74 + 0x4에 있습니다. 0x74는 12바이트 필드가 시작되는 곳이고, 0x4는 i_osd2inode l_i_uid_high시작 입니다. 정량적 분야 i_osd2. 이는 한때 "전 세계가 16비트 사용자 ID"였기 때문에 초기 파일 시스템이 사용자 ID의 첫 번째 필드만 예약했기 때문일 수 있습니다. 32비트 사용자 ID가 필요한 경우 다른 필드가 이미 존재하기 때문에 두 번째 16비트를 인접하게 배치할 수 없으므로(이 경우 i_size필드는 원래 32비트로 제한되었지만 너무 작아서) 끝에 i_size_fieldan이 추가되어 또 다른 32비트 크기를 얻었습니다(inode의 오프셋 0x6C 참조). 따라서 사용 가능한 inode에서 사용되지 않은 첫 번째 위치에 배치될 수 있습니다.
이러한 복잡성은 주로 이전 버전과의 호환성 고려 사항(ext4는 사용자가 특별한 작업을 수행하지 않고도 ext3 파일 시스템을 읽을 수 있기를 원함)과 향후 확장을 수용하려는 욕구 때문입니다. 20/20을 기준으로 흩어진 부분을 모두 합칠 수 있으며 예를 들어 두 부분으로 분할하지 않고도 i_uid유형을 볼 수 있습니다. __le32하지만 그것이 바로 이전에 일어났던 일을 놓지 않고 앞으로 나아가기 위해 해야 할 일이다.