Nextcloud(Linux/Nginx/PGsql/PHP) 서버가 마운트된 회전 하드 드라이브에서 폴더를 찾도록 구성하는 대신 해당 폴더에 대한 /mnt/HDDfs/심볼릭 링크를 만든 다음 Nextcloud 구성을 해당 폴더로 지정했습니다 . 이렇게 하면 마운트 지점의 이름을 변경하기로 결정한 경우 간단히 심볼릭 링크를 편집할 수 있으므로 데이터베이스를 건드릴 필요가 없습니다./var/Nextcloud_Data/mnt/HDDfs/Nextcloud_Data/var/Nextcloud_Data
처음에는 좋은 생각 같았지만 내 루트 /드라이브는 기존 디스크에 비해 제한된 마모만 견딜 수 있는 SSD라는 사실을 기억했습니다. 심지어 오늘날의 디스크도 드라이브의 특정 셀을 반복적으로 두드려도 마모가 거의 발생하지 않습니다. 최선의 아이디어도 아닙니다.
내가 묻는 것은 프로그램이 심볼릭 링크가 있는 위치에 로드 및/또는 쓸 때 운영 체제가 매번 소스 위치에서 심볼릭 링크를 로드한 다음 이를 실제 대상으로 따라가서 작업을 수행하는 것입니다. 아니면 심볼릭 링크를 "캐시"하고 /var/Nextcloud_Data/filename직접 변환합니까 /mnt/HDDfs/Nextcloud_Data/filename?
추가 정보:
- 운영 체제: 모든 최신 패치와 업그레이드가 포함된 Ubuntu Server 18.04 LTS.
- 디스크 드라이브: WD RED 하드 드라이브 및 SATA를 통해 연결된 PCIe M.2(Samsung 960 EVO) SSD.
- 파일 시스템: 두 드라이브 모두 GPT 형식입니다.외부 4파일 시스템.
- 마더보드: ASUS Z170-Deluxe(데스크탑 마더보드)
답변1
괜찮아요. 이유는 많아요.
첫째, 플래시 드라이브는 읽기 횟수가 아닌 쓰기 횟수에 중점을 둡니다.
둘째, 이 문제는 펌웨어나 드라이버가 불량한 구형 또는 저렴한 드라이브에 적용되지만 최신 운영 체제의 최신 드라이브에는 적용되지 않습니다. 최신 SSD는 웨어 레벨링이 충분하며 최신 운영 체제에는 덮어쓰기와 삭제를 구별하는 드라이버가 있습니다(치다) 따라서 쓰기 횟수에 주의를 기울이기 시작하는 데 오랜 시간이 걸립니다. 이 시기에는 잘못된 위치의 습기나 먼지, 기계적 손상과 같은 기계적 관련 이유로 인해 자기 드라이브가 고장나는 경우가 많습니다.
시스템 구성에 따라 심볼릭 링크를 읽으면 액세스 시간이 업데이트될 수 있습니다.기본적으로 Linux는 하루에 한 번만 파일 액세스 시간을 업데이트합니다.. 따라서 드라이브에 대한 쓰기 횟수가 걱정되더라도 심볼릭 링크를 통한 한 번의 액세스와 달리 한 번의 쓰기는 하루가 됩니다.
커널은 디스크에서 읽은 다른 정보와 마찬가지로 디스크 캐시에 기호 링크에 대한 정보를 보관합니다. "리디렉션 대상"이라는 캐시는 유지하지 않지만 "대상이 있는 심볼릭 링크"라는 캐시는 유지합니다. 이는 캐시 항목이 여전히 존재하는 한 드라이브에서 읽을 수 없음을 의미합니다. 이는 액세스 시간이 업데이트되는 빈도와는 아무런 관련이 없습니다. 이는 드라이브에서 파일에 대한 정보를 전송하는 데 걸리는 시간이 아니라 파일에 액세스하는 데 걸리는 시간의 함수입니다./var/Nextcloud_Data/filename/mnt/HDDfs/Nextcloud_Data/filename/var/Nextcloud_Data/mnt/HDDfs/Nextcloud_Data