파일 업로드를 처리하는 기능을 구축할 때 프로그래밍의 일반적인 추세는 먼저 파일을 임시 디렉터리/폴더(예: Linux의 /tmp)에 업로드하는 것 같습니다. 파일이 완성되면 임시 디렉터리에서 이동하여 지정된 디렉터리에 저장합니다. 일부 프로그래밍/스크립팅 언어는 기본적으로 진행 중인 업로드를 /tmp에 배치하고 다른 언어는 그렇지 않지만 일반적인 관행은 업로드가 완료될 때까지 /tmp를 자리 표시자 디렉토리로 명시적으로 설정하는 것입니다. 이때 업로드는 별도의 디렉토리로 이동됩니다.
장기 저장을 위해 파일을 다른 파티션/디렉터리로 이동하기 전에 임시 "보유" 디렉터리를 사용하여 콘텐츠를 업로드하면 어떤 이점이 있습니까?
저는 대용량 데이터(TB)의 영구 저장을 위해 NFS를 통해 (내부) 네트워크 스토리지를 가상 머신에 마운트하는 환경에서 작업하고 있습니다. 기술이 발전함에 따라 우리는 더 빠르고 더 많은 양의 데이터를 얻을 수 있습니다. 몇 년 전에는 파일의 간단한 HTTP 업로드(상대적으로 작은 파일 크기, 메가바이트?)였지만 이후에는 플래시 업로드로 전환했습니다. 이제 일부 브라우저에서는 기가바이트 파일/폴더 구조까지 업로드를 끌어서 놓을 수 있습니다. 사용자가 실제로 한 번에 충분한 파일을 업로드하려는 경우 /tmp에 예약된 파티션을 쉽게 초과할 수 있는 지점에 이르렀습니다. NFS를 통한 마운트의 네트워크 대기 시간 외에도 /tmp를 파일 서버에 직접 보내는 것보다 확장하면 어떤 이점이 있습니까? 기술을 통해 불과 10년 전만 해도 상상할 수 없었던 방대한 양의 데이터에 액세스할 수 있게 되면서 이러한 전통적인(지금은 나쁜) 관행이 쓸모 없게 되어가고 있습니까?
답변1
- 지정된 저장소 디렉터리가 네트워크 저장소라면 성능을 위한 것인가요?
- 예, 그럴 수도 있습니다. 비록 일반적으로 그렇지는 않지만요. 실제 업로드 성능이 코드의 주요 성능 문제가 되는 경우는 거의 없습니다.
- Linux는 개발자/관리자가 다른 곳에서 설명할 필요가 없도록 /tmp 디렉토리를 정기적으로 스캔하여 오래된 파일을 제거합니까?
- 네, 대개 그렇습니다. 이는 업로드 관리자 프로세스가 충돌하고 그렇지 않으면 정리되지 않는 일부 파일이 남겨지는 상황도 포함합니다.
- 단지 이것 때문일까요?
- 예. :-)
- 최종적으로 저장될 디렉터리에 파일을 간단히 작성할 수 있는 기회가 있다면(예: node.js의 fs 모듈 사용) 그렇게 해야 합니까? 아니면 이것이 금기인가?
- 임시 스크래치 디렉토리를 사용하고 이를 대상 디렉토리와 동일한 파일 시스템에 배치하는 데는 이유가 있습니다. 많은 응용 프로그램은 이 디렉터리를 최종 대상 디렉터리와 동일한 파일 트리에 배치하므로 최종 "이동" 작업은 거의 즉각적으로 이루어집니다(아마도 원자적일 수 있음). 따라서
/var/spool/myapp/tmp및 와 같은 내용을 자주 보게 됩니다/var/spool/myapp/data. 그러나 응용 프로그램은 일반적으로cron정리 작업을 추가합니다.../tmp.
- 임시 스크래치 디렉토리를 사용하고 이를 대상 디렉토리와 동일한 파일 시스템에 배치하는 데는 이유가 있습니다. 많은 응용 프로그램은 이 디렉터리를 최종 대상 디렉터리와 동일한 파일 트리에 배치하므로 최종 "이동" 작업은 거의 즉각적으로 이루어집니다(아마도 원자적일 수 있음). 따라서
답변2
이는 실제로 시스템에 무엇이 있고 어떻게 사용되는지에 따라 달라집니다.
일부 시스템에서는 /tmp일반적으로 시스템 파일이나 스왑 공간에 사용됩니다. 솔라리스를 채우신다면 /tmp,나쁜 일이 일어나다(그리고 관련된 일화). 이 경우 누군가가 이 볼륨을 채우는 파일을 업로드하면 시스템이 중단될 수 있습니다. 발생할 수 있는 또 다른 문제는 일부 응용 프로그램이 자체 임시 파일에 쓸 수 없다는 것입니다.
과거에는 사람들이 멍청하지 않고(적어도 9월이 아닌 이상) 악의가 매우 낮을 것이라고 합리적으로 믿을 수 있었습니다. 오늘은...그건 다른 이야기입니다.
이것이점작성하는 이유 /tmp는 머신의 로컬 파일 시스템이 보장되고 존재하며 순찰된다는 것입니다(스크립트는 자동으로 오래된 파일을 삭제합니다). 체계필요/tmp시스템의 합리적인 성능을 위해서는 시작 하고 빠른 액세스가 필요합니다. 파일을 어딘가에 빠르게 작성한 다음 다른 곳으로 옮기고 싶으십니까? 에 넣으세요 /tmp.
완전히 로드될 때 나쁜 일이 발생할 수 있다는 점을 고려하면 /tmp동일한 이점을 제공하는 다른 대안을 고려해야 합니다. 예를 들어 완전히 로드될 때 시스템이 충돌하지 않는 파일을 업로드하기 위해 마운트된 파티션을 생성하는 등이 있습니다.
또 다른 고려 사항은 "빠른" 비트입니다. 고대부터 드라이브는 점점 더 빨라졌습니다. 훨씬 더 빠릅니다. 좋은 SSD는 그 순간 무엇이든 파괴할 수 있습니다. 하지만 그거 아시나요?진짜업로드된 파일을 쓰려면 SSD가 필요합니까? 다이빙이 빨라졌을 뿐만 아니라 네트워크도 빨라졌습니다. 업로드된 파일을 네트워크 저장소 영역에 기록하면 단일 지점에서 도움이 될 수 있습니다. 여러 시스템에서 파일을 중앙 지점에 업로드하면 다른 프로세스가 해당 파일을 스캔하고 올바른 위치로 이동할 수 있습니다.
그래서... 요약하자면:
- 예전에는 장점이 있었는데
- 웹보다 빠르고 항상 존재합니다.
- 문제를 일으킬 수 있다
- 옛 시절은 지나갔다
- 더 빠른 드라이브 및 네트워크
- 사람들은 바보야, 공격자가 더 많아
그래서 저는 아니오라고 말하고 싶습니다. /tmp기본 답변으로 글쓰기를 중단하십시오. 디스크 사용 정책에 맞는 쓰기 위치에 대해 시스템 관리자에게 문의하고 로컬 시스템에서 완전히 벗어난 곳에 쓰는 것을 고려하십시오.
답변3
/tmp파일을 저장하기에 편리한 장소이자 파일이 정리될 것이라고 합리적으로 확신할 수 있는 곳(예를 들어 웹 애플리케이션이 정리되지 않는 경우)입니다. 따라서 이는 합리적인 기본값입니다.
자신이 업로드한 파일의 경로를 지정할 수 있는 옵션이 있는 경우 최종 대상과 동일한 마운트 경로로 설정해야 할 이유가 있습니다. 이렇게 하면 원자 이름 바꾸기를 사용하여 파일을 최종 대상 위치로 가져올 수 있습니다. (교차 설치인 경우 복사본을 만들어야 합니다.)
(예를 들어) 업로드가 중간에 중단되면 거기에 부분 파일이 남을 수 있기 때문에 최종 대상에 업로드하지 않을 것입니다. 또는 스크립트가 실패하면 데이터베이스에서 참조하지 않는 고아 파일이 남을 수 있습니다.
참고: 클라이언트가 제공한 파일 이름은 신뢰할 수 없는 데이터라는 점을 기억하세요. 악의적인 사용자가 쉽게 파일 이름을 제공할 수 있으며 ../../../something, 주의하지 않으면 의도하지 않은 내용을 작성할 수도 있습니다.