누군가 간단한 대답을 하기 전에 내 SSD는아니요모든 것을 담을 수 있을 만큼 큽니다. 광산은 /home대략 데이터, 문서 및 가상 머신으로 채워져 있습니다. 720GB. 더 큰 SSD를 사고 싶지 않습니다.
오늘날의 SSD는 단지 140GB SATA 디스크일 뿐입니다 /dev/sda. 내 하드 드라이브 /dev/sdb는 (현재) 다른 이야기입니다. 용량은 2TB입니다. HDD에는 현재 Linux 설치가 포함되어 있으며 관련 없는 몇 가지 이유로 이를 오래된 데비안 설치로 교체해야 합니다. 이 시스템은 약간의 짐승(16개 코어, 32GB RAM)이며 암호화된 LVM을 사용합니다.
(이유는 성능과는 관련이 없습니다. 현재 배포판(기본 OS)에서 내린 결정으로 인해 업그레이드에 막다른 골목에 부딪혔고, 드디어 할 시간을 찾았습니다. 이 게시물은 In에 없습니다. distro 불꽃 전쟁을 시작하거나 Elementary OS 6이 좋은 선택인지 논의하기 위해 한 번 설치하고 영원히 업그레이드하는 접근 방식을 믿기 때문에 Arch 및 기타 배포판에 오랫동안 시간을 투자할 시간이 부족합니다. (15년 이상) 저는 항상 정보를 찾는 사람이었고 계속해서 정보를 찾을 계획입니다. 다양한 옵션이 있어서 다행입니다.
그래서 다시 질문으로 돌아가서, 어차피 새로 설치하는 중이니까 SSD 가속을 활용하기 좋은 때인 것 같았습니다.
물론, 쓰기 주기 제한으로 인해 최근 몇 년간 나아졌음에도 불구하고 마모를 최소화하면서 실제로 가장 큰 이점을 제공하는 파티션만 SSD에 배치하고 싶습니다. 내 직감으로는 파티션이 많은 읽기 작업을 수행하지만 쓰기 작업은 수행하지 않을 것이라는 것입니다. 초기 선택의 좋은 세트는 /boot, /및 입니다 /usr/local./opt
18년 전 Slackware 시스템을 호스팅한 이후로 저는 항상 별도의 파티션에 시스템을 /tmp보관해 왔습니다. /var/log좋은 습관은 죽기 어렵습니다.
다음은 좋은 계획인가요?
/boot 1GB SSD
/boot/efi 650 M SSD
/ 50 GB SSD
/usr/local 50 GB SSD
/opt 38 GB SSD
swap 64 GB HD
/var/log 20 GB HD
/tmp 20 GB HD
/home 1.89 TB HD
?
변경사항을 제안해 주세요. 관련성이 있을 수 있는 한 가지는 기본 Microsoft Word 설치가 필요한 드문 경우를 위해 가상 머신에서 Windows 10을 실행한다는 것입니다. docker 또는 kvm 이미지를 별도의 별도 파티션에 배치하는 것이 가치가 있습니까? 사람들이 겪고 있는 약간의 지연을 극복하기 위해 이들 중 하나를 SSD에 넣을 수 있습니까? 이미지가 SSD에 있어도 Docker 로깅이 HD에 유지되도록 하는 방법은 무엇입니까?
답변1
이곳은 내 경험을 공유할 수 있는 좋은 장소입니다.
SSD+HDD에 매우 사용자 정의된 파일 시스템이 설정된 HP ProBook에 Gentoo를 설치했습니다. 이것이 제가 지금 이 글을 쓰고 있는 시스템입니다.
SSD(sda)용 GPT 파티션은 3개, HDD(sdb)용 GPT 파티션은 2개입니다.
SSD(sda1)의 첫 번째 파티션인 127M은ESP, grub 구성, 커널 및 initramfs를 호스팅하는 부팅 파티션이기도 합니다. ESP를 마운트할 /boot/efi가 없습니다. /boot는 이미 ESP이고 /boot/EFI 및 /boot/grub 등이 포함되어 있습니다. 이것은 문제가 되지 않습니다.
HDD의 첫 번째 파티션(sdb1)인 127M은 사용되지 않습니다. 그 목적은 "ESP를 위한 여유 공간"이 되는 것입니다.
SSD의 두 번째 파티션(sda2)은 20G로 캐시 장치이고, HDD의 두 번째 파티션(sdb2)은 디스크 전체(500G)를 채우는 백엔드 장치입니다. 이 두 개는캐시 하드 드라이브—bcache0.
이 bcache0은암호화된 볼륨, 이는 LVM의 PV이며 pv1이라고 합니다.
SSD의 세 번째 파티션(sda3), 즉 남은 공간 역시 pv0이라는 LVM PV를 포함하는 암호화된 볼륨입니다.
pv0과 pv1은 다음을 구성합니다.좌심실 용적VG. 모든 볼륨이 암호화되어 있기 때문에 안전한 곳이라고 생각합니다. VG는교환pv0에 배치되어 최대 절전 모드에 사용됩니다(RAM과 거의 같은 크기).읽기 전용 루트다시 pv0의 파일 시스템은 squashfs(현재 약 7G)입니다.r/w ext4 루트 재정의또한 pv0에도 공간이 남아 있지 않습니다. 이것/집pv1에 위치하지만 약 300G에 걸쳐 있으므로 약간의 공간이 남아 있습니다.
이것사용자 정의 initramfs 스크립트캐시를 조립하고, 암호화를 잠금 해제하고, VG를 조립합니다. 오버레이를 마운트하고, squashfs를 마운트한 다음, 오버레이 파일 시스템을 마운트합니다. 여기서 하위 계층은 squashfs이고 상위 계층은 오버레이의 디렉터리입니다. 그런 다음 switch_root 이후 모든 것이 잘 보이도록 마운트를 다시 정렬한 다음 루트를 전환합니다.
이 설정을 성공적으로 사용했습니다.1년 반. 업그레이드는 매우 쉬웠습니다. 평소처럼 시스템을 업그레이드하고( emerge -av... @world) 모든 것을 오버레이에 넣은 다음 업그레이드된 루트에서 새 squashfs를 만든 다음 이전 squashfs와 오버레이를 하드 드라이브(pv1)로 pvmove하고 이를 위해 생성했습니다. 새 볼륨은 SSD(pv0)에 있습니다. init 스크립트는 업데이트된 볼륨을 식별하고 루트를 어셈블하기 전에 모든 이름을 바꾸므로 재부팅 후에는 새 볼륨 세트가 루트를 차지합니다. 하지만 이전 버전은 여전히 남아 있습니다. 업그레이드를 복원하려면 덮어쓰기를 지우고 재부팅하면 됩니다. 또한 이전 업그레이드 지점으로 돌아갈 수 있도록 외부 HDD에 이전 squashfs(및 보관된 /boot)의 추적을 유지합니다.
설정이 매우 복잡해 보였기 때문에 문제를 수정해야 할 경우를 대비해 스크립트를 사용하여 Live CD 환경에서 조립하기도 했습니다.
당신의 계획에 대해.
ESP+/boot에 1G + 650M을 낭비하기에는 너무 욕심이 많습니다. 나는 이것을 위해 단지 1억 2,700만 달러를 투자했는데, 이는 당신이 계획한 것보다 10배 적은 금액입니다. 23M만 사용하기 때문에 이것은 여전히 너무 많은 것입니다!
내 루트 FS에는 일부 게임, STM32CubeIDE 및 해당 다운로드(약 3~4G), 패키지 관리자 데이터베이스(포티지) 및 기타 대규모 blob을 포함하여 약 20G의 원시 데이터가 있습니다. 약 7G로 압축되었습니다. 접근 속도가 빠르고, squashfs 덕분에 어떤 악의적인 행위자도 침입하기가 매우 어렵습니다.
/var/usr/local별도의 파티션을 두거나 별도의 파티션 에 넣는 데 아무런 이점이 없습니다 /opt. 20년 이상의 Linux 경험을 통해 이것이 어떤 식으로든 도움이 되는 상황을 본 적이 없습니다. 사실은 정반대입니다. 나는 그것들이 모두 일관되고 서로 연관되어 있기를 원하므로 단일 파일 시스템에 넣는 것이 더 쉬울 것이라고 생각합니다. 나는 그것을 "시스템" 또는 "루트"라고 부르며 전체적으로 관리합니다(백업, 순환 업데이트). 그렇기 때문에 나는 "혼자 /usr" 같은 문제를 겪어본 적이 없으며 그런 사람들을 비웃습니다.
별도의 파티션을 갖는 것이 좋습니다 /home. 백업 전략이 매우 다르며 파일 시스템의 목적도 완전히 다릅니다. 하지만 여기서는 /home특히 시스템에 로그인하거나 애플리케이션(프로필 및 구성)을 시작할 때 많은 작은 파일을 읽고 써야 한다는 점을 명심하세요 . 인지된 기계 반응성을 위해서는 /homeSSD를 사용하는 것이 SSD에 시스템을 설치하는 것보다 더 중요합니다! 이것이 바로 /home 경험을 향상시키기 위해 캐싱을 사용하는 이유입니다.
답변2
내가 당신에게 드리는 조언은 이것입니다
- 과도한 읽기/쓰기와 파티션 생성 위치 또는 방법에 대해 걱정하지 마십시오. Linux는 디스크 캐싱에 RAM을 사용하며 1GB 대신 32GB의 RAM이 있습니다.
systemctl enable tmp.mount. 이는/tmp디스크 대신 메모리를 사용하는 올바른 방법입니다.- 저는 RHEL/CentOS를 사용하고 있으며 이는
XFS파일 시스템의 기본값입니다. 내 파티션 구성표는 다음과 같습니다
..
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 95M 10M 85M 11% /boot/efi
/dev/sda2 950M 237M 714M 25% /boot
/dev/sda3 3.5T 176G 3.4T 5% /
/dev/sdb1 18T 5.0T 13T 29% /data
XFS 또는 EXT4를 파일 시스템으로 사용하는 것이 좋습니다. 귀하의 크기는 분명히 내 것과 다를 것입니다. 표준 기본 규칙은 /home/사용자 계정에 적용됩니다. 이것은 /내 것과 같은 루트 파티션 아래에 있을 수도 있고 (모든 디스크에) 완전히 별도의 디스크 파티션을 만들 수도 있습니다./home 또는사용자 계정을 지정된 위치에 배치할 수 있습니다. 내 경우 /etc/default/useradd에는 HOME=/data/users내 계정(관리자)만 /home 아래에 있고 모든 사용자 계정이 내 /data 볼륨 아래에 있다는 것이 요점이었습니다. 이는 많은 디스크에 대한 하드웨어 습격이었지만 귀하의 경우에는 별도의 디스크일 수 있습니다.
어려운 방법을 배우기 전에 지금 데이터 관리 및 구성에 대해 알아보십시오.
시스템이 데이터가 중요한 다중 사용자 작업 환경 유형인 경우 시스템에 총 3개 이상의 디스크가 있어야 합니다. 운영 체제용 디스크가 죽으면 운영 체제를 다시 설치하지만 중요한 데이터는 저장되지 않습니다. 두 번째 디스크는 다음과 같이 마운트되고 /data세 번째 디스크는 /bkup어떻게든 설치한 위치에 마운트됩니다(참조:스냅 사진/data/bkup)는 데이터 디스크 손상을 방지하기 위해 에서 까지의 모든 데이터를 가능한 한 자주 복사합니다 . 모든 디스크의 모든 파티션에서 모든 디렉토리를 마운트할 수 있지만 Linux는 상관하지 않으므로 필요에 맞게 구성하십시오. 나는 가능한 한 간단하게 유지하는 것을 선호합니다.
이미지가 SSD에 있어도 Docker 로깅이 HD에 유지되도록 하는 방법
어디에나 쓸 수 있도록 docker(또는 기타) 로깅을 구성하지만 그렇지 않습니다.가지다해고됨 /var/log. 따라서 많은 로그를 보관해야 할 것으로 예상되는 경우 어떤 디스크에 가장 많은 공간이 있는지 알아내는 것이 가장 실용적이며 루트 파티션과 동일한 디스크에 있을 필요는 없습니다. 개념을 더 잘 설명하기 위해 위의 파티션 구성표를 예로 들었습니다. 이 4개의 파티션 구성표는 각각 다른 파티션에 있을 수 있습니다.디스크원하는 경우, /usr다른 디스크나 파티션 또는 디렉터리에서 /home설치 /opt하고 LUKS를 사용하여 Linux에서 의미 있는 모든 것을 암호화하는 것(서버에서 자체 암호화 디스크를 사용하지 않는 경우)이 지원됩니다. 귀하의 경우에는 드라이브 베이와 더 큰 크기의 추가 디스크/SSD 구매 기능이 제한될 것으로 생각됩니다. 도움이 되길 바랍니다.