많은 사람들은 그들이 문제를 가지고 있다고 생각한다. 하지만 실제로 그렇지 않다. 또는 그들은 그들이 가지고 있는 문제가 디스크 구조정보 때문이라고 생각한다. 그러나 디스크 구조정보는 이러한 문제와 연관이 없다. 위에 말이 복잡하게 들릴지 모르지만, 디스크의 구조정보 조작은 너무도 쉽다 : 아무 것도 해줄 필요가 없다. 그냥 그대로 모든 것이 정상적이다. 또는 부팅시 `LI' 가 나타나며 더 이상 진행하지 않는 경우 LILO 에서 `linear' 키워드를 주라. 커널의 부팅 메세지를 보아라. 그리고 기억하라.: LILO나 fdisk등에 head나 cylinder를 입력하는 등의 구조정보를 가지고 시간을 허비하는 일은 하면 할 수록 일이 진행가능성은 줄어 들 것이다. 개략적으로 말하면 모든것이 기본적으로 정상적이다.
그리고 기억하라: 디스크의 구조정보가 사용되는 곳은 리눅스 상에 어디에도 없다. 그러므로 리눅스를 운영하는 동안 디스크 구조정보에 의해 문제를 겪게될 일은 없다. 디스크 구조정보는 단지 LILO와 fdisk에 의해서만 사용된다. 그러므로 LILO가 커널을 부팅하는데 실패하면, 이것은 구조정보 문제인 것이다.
만약 다른 운영체제 시스템이 파티션 테이블을 인식하지 않으면 이것은 구조정보 때문일 것이다. 특별한 다른 이유가 없다. 마우트가 제대로 되지 않더라도 디스크 구조정보에 대해 걱정할 필요가 없다. 문제는 다른 곳에 존재한다.
디스크가 잘못된 구조정보를 갖는 것은 가능하다. 리눅스 커널은 BIOS에게 hd0 와 hd1을 요구한다.(BIOS 상에서 드라이브는 80H와 81H 간주된다) 그리고 이 데이터가 hda와 hdb에 대한 것으로 간주한다. 그러나 SCSI로 부팅하는 시스템에서 처음 두개의 디스크는 아마도 SCSI 디스크가 될 것이다. 그래서 첫번째 IDE 디스크 hda인 5번째 디스크가 sda에게 해당되는 구조정보를 갖게 된다. 이러한 문제는 부팅 파라메터를 다음과 같이 입력 하므로서 해결된다. C, H, S 의 적당한 값 `hda=C,H,S'를 부팅시 또는 /etc/lilo.conf에 설정하므로서 해결된다.
`저는 동일한 10 GB의 IBM 디스크를 갖고 있습니다. 그런데 fdisk는 이들 디스크의 크기상에 차이를 보여줍니다.' 아래처럼 :
# fdisk /dev/hdb
Disk /dev/hdb: 255 heads, 63 sectors, 1232 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hdb1 1 1232 9896008+ 83 Linux native
# fdisk /dev/hdd
Disk /dev/hdd: 16 heads, 63 sectors, 19650 cylinders
Units = cylinders of 1008 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hdd1 1 19650 9903568+ 83 Linux native
어떻게 이런 결과가 ?
무슨 문제가 생긴 걸까요 ? 무엇보다도 모든 이러한 드라이브는 실제로
10 기가 바이트입니다.
hdb는 255*63*1232*512 = 10133544960크기를 갖으며,
hdd는 16*63*19650*512 = 10141286400크기를 갖습니다. 그러므로 잘못된 것은
없습니다. 그리고 커널은 이 둘 모두를 10.1 GB로 인식합니다.
그럼 왜 크기상에 차이가 있는 건가요 ? 그것은 커널이 처음 두개의 IDE 디스크의
정보를 BIOS로 부터 가져 오기 때문입니다.
그리고 BIOS는 hdb 를 255 개의 헤드를 갖는 것으로 재할당했기 때문입니다.
(and 16*19650/255=1232 cylinders).
여기에서 자리 내림은 약 8 MB 공간을 깍아 먹습니다.
만약 hdd도 동일한 방법으로 재할당되길 원한다면 부팅파라메터를 `hdd=1232,255,63'으로 입력해 주면 됩니다.
fdisk는 디스크상에 얼마나 많은 블록이 있는지를 보여줄 것입니다. 만약 여러분이 디스크상에 파일시스템을 생성시 mke2fs 를 이용하면, 이 파일 시스템은 시스템 용도(bookkeeping)를 위해 약간의 공간을 필요로 합니다. 일반적으로 파일시스템 크기의 4% 정도를 사용합니다. 게다가 mke2fs 실행시 많은 inode를 여러분이 요구하면 더욱더 많이 여분의 공간으로 사용됩니다.
예를 들어:
# sfdisk -s /dev/hda9
4095976
# mke2fs -i 1024 /dev/hda9
mke2fs 1.12, 9-Jul-98 for EXT2 FS 0.5b, 95/08/09
...
204798 blocks (5.00%) reserved for the super user
...
# mount /dev/hda9 /somewhere
# df /somewhere
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda9 3574475 13 3369664 0% /mnt
# df -i /somewhere
Filesystem Inodes IUsed IFree %IUsed Mounted on
/dev/hda9 4096000 11 4095989 0% /mnt
#
우리는 4095976개의 블럭을 갖는 파티션을 갖는다. 그리고 이 파티션에 ext2 파일 시스템을 생성한다. 그리고 마우트를 하고나서 이 시스템이 단지 3574475 블럭을 갖는 것을 알게 되었다. 521501 블럭(12%)이 inode와 시스템 용도(bookkeeping) 용도로 이용되었다. 전체크기 3574475 와 사용자가 사용할 수 있는 크기의 차이는 사용중인 13개의 블럭에 루트를 위해 예약된 204798 블럭을 합한것과 같다는 것을 주목하기 바란다. 204798 의 블럭 수치는 tune2fs에 의해 변경 가능하다. 이 `-i 1024'는 단지 news 스풀이나 기타 매우 작은 파일들이 많은 경우에 적당하다. 기본값은 다음과 같다.
# mke2fs /dev/hda9
# mount /dev/hda9 /somewhere
# df /somewhere
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda9 3958475 13 3753664 0% /mnt
# df -i /somewhere
Filesystem Inodes IUsed IFree %IUsed Mounted on
/dev/hda9 1024000 11 1023989 0% /mnt
#
이제 단지 137501 blocks (3.3%) 이 inode로 사용된다. 그러므로 우리는 이전보다 384 MB 를 더 사용할 수 있다. (정확하게 각각의 inode는 128 byte를 갖는다) 반면에 이 파일시스템은 이전의 4096000 에 비해 충분한 크기인 1024000 개의 파일을 갖을 수 있다.