영구 저장소로 이동하기 전에 /tmp에 파일을 업로드하면 이점이 있습니까?

Question

파일 업로드 처리 기능을 구축할 때 프로그래밍의 일반적인 추세는 파일을 먼저 임시 디렉터리/폴더(예: Linux의 /tmp)에 업로드하는 것입니다. 파일이 완성되면 임시 디렉터리에서 이동하여 지정된 디렉터리에 저장됩니다. 일부 프로그래밍/스크립팅 언어는 기본적으로 진행 중인 업로드를 /tmp에 배치하는 반면 다른 언어는 그렇지 않습니다. 그러나 업로드가 완료될 때까지 /tmp를 자리 표시자 디렉토리로 명시적으로 설정하는 것이 일반적인 관행으로 보입니다. 별도의 디렉토리.

장기 저장을 위해 파일을 다른 파티션/디렉터리로 이동하기 전에 임시 "보유" 디렉터리를 사용하여 콘텐츠를 업로드하면 어떤 이점이 있습니까?

저는 대용량 데이터(테라바이트)를 지속적으로 저장하기 위해 (사내) 네트워크 스토리지가 NFS 마운트를 통해 가상 머신에 마운트되는 환경에서 작업하고 있습니다. 기술이 발전함에 따라 우리는 데이터를 더 빠르게, 훨씬 더 많은 양으로 수집할 수 있게 되었습니다. 몇 년 전에는 한 번에 하나의 파일(상대적으로 작은 크기, 메가바이트?)을 HTTP로 업로드하는 간단한 방법을 사용하다가 플래시 업로드로 전환했습니다. 이제 우리는 일부 브라우저에서 기가바이트 영역의 파일/폴더 구조를 업로드할 가능성이 있는 경우에도 드래그 앤 드롭 업로드를 사용할 수 있습니다. 한 사용자가 실제로 한 번에 충분한 양을 업로드하려는 경우 /tmp에 대해 별도로 설정된 파티션을 쉽게 초과할 수 있는 지점에 도달했습니다. NFS 마운트를 통한 네트워크 대기 시간을 제외하고 /tmp를 파일 서버로 직접 보내는 것보다 확장하면 어떤 이점이 있습니까? 기술 덕분에 10년 전에는 상상할 수도 없었던 엄청난 양의 데이터를 수집할 수 있게 되었는데, 이것이 이제 구식이 되어버린 레거시(지금은 나쁜) 관행입니까?

Answer 1

1. 지정된 저장소 디렉터리가 네트워크 저장소인 경우 성능을 위한 것인가요?
   • 예, 그럴 수도 있습니다. 하지만 일반적으로는 그렇지 않습니다. 실제 업로드 성능이 코드의 주요 성능 문제가 되는 경우는 거의 없습니다.
2. Linux는 정기적으로 [해당] /tmp 디렉토리를 스캔하여 오래된 파일을 삭제하므로 개발자/관리자가 다른 곳에서 이에 대해 설명해야 하는 수고를 덜게 됩니까?
   • 예, 일반적으로 그렇습니다. 여기에는 업로드 관리자 프로세스가 충돌하고 그렇지 않으면 정리되지 않는 부분 파일이 남겨지는 경우도 포함됩니다.
3. 단지 그렇기 때문에 그런 것인가?
   • 예. :-)
4. 파일을 디렉토리에 간단히 쓸 수 있는 기회가 주어진다면 궁극적으로 (예: node.js의 fs 모듈 사용) 저장될 것입니다. 해야 할까요, 아니면 안 됩니까?
   • 임시 준비 디렉터리를 사용하고 이를 대상 디렉터리와 동일한 파일 시스템에 배치하는 데는 이유가 있습니다. 많은 응용 프로그램은 이 디렉터리를 최종 대상 디렉터리와 동일한 파일 트리에 넣으므로 최종 "이동" 작업은 거의 즉각적이며 잠재적으로 원자적입니다. 따라서 /var/spool/myapp/tmp와 같은 것을 자주 보게 될 것입니다 /var/spool/myapp/data. 그러나 애플리케이션은 종종 .NET 파일 cron에서 오래된 파일을 정리하는 작업을 추가합니다 .../tmp.

Answer 2

이는 실제로 시스템에 무엇이 있는지, 그리고 사물이 어떻게 사용되는지에 따라 달라집니다.

일부 시스템에서는 /tmp일반적으로 시스템 파일이나 스왑 공간에 사용됩니다. /tmp솔라리스를 채우신다면 ,나쁜 일이 일어나다(그리고 관련된 일화). 이러한 경우 누군가가 이 볼륨을 채우는 파일을 업로드하면 시스템이 중단될 수 있습니다. 발생할 수 있는 다른 상황은 특정 응용 프로그램이 자체 임시 파일을 작성할 수 없다는 것입니다.

옛날에는 사람들이 바보가 아니라는 것을 합리적으로 믿을 수 있었고(적어도 9월 제외) 악의도 합리적으로 낮았습니다. 오늘은... 그건 다른 이야기입니다.

그만큼이점쓰기 위해서는 /tmp머신의 로컬 파일 시스템이 존재하고 순찰된다는 것이 보장됩니다(오래된 파일을 자동으로 삭제하고 삭제하는 스크립트). 시스템필요한/tmp시스템의 합리적인 성능을 위해서는 부팅과 이에 대한 빠른 액세스가 필요했습니다 . 따라서 파일을 어딘가에 빠르게 작성한 다음 다른 곳으로 옮기고 싶습니까? 에 넣으세요 /tmp.

/tmp가득 찼을 때 나쁜 일이 발생한다는 점에 대해 동일한 이점을 제공하는 다른 대안을 살펴봐야 합니다. 예를 들어 파일을 업로드하기 위해 마운트된 파티션을 만들어서 가득 차도 컴퓨터가 충돌하지 않도록 하는 것입니다.

하지만 또 다른 고려 사항은 '빠른' 비트입니다. 옛날부터 드라이브 속도가 빨라졌습니다. 훨씬 더 빠릅니다. 좋은 SSD는 그 당시의 모든 것을 날려버릴 수 있습니다... 하지만 당신은 그렇게 합니까?정말업로드 파일을 쓰려면 SSD가 필요합니까? 다이빙이 더 빨라졌을 뿐만 아니라 네트워크도 더 빨라졌습니다. 업로드 파일을 네트워크 저장소 영역에 기록하면 여러 시스템이 파일을 중앙 지점에 업로드할 수 있는 단일 지점에 도움이 될 수 있으며, 중앙 지점에서는 다른 프로세스가 해당 파일을 스캔하고 적절한 위치로 이동할 책임을 맡을 수 있습니다.

그래서... 요약하자면:

• 옛날에는 장점이 있었지
  • 네트워크보다 빠르고 항상 존재합니다.
• 문제가 발생할 수 있음
• 옛 시절은 더 이상 여기에 있지 않습니다.
  • 드라이브 및 네트워크 속도 향상
  • 사람들은 더 멍청하고 더 공격적이다

/tmp그래서 저는 아니오라고 말하고 싶습니다. 더 이상 기본 답변으로 편지를 쓰지 마십시오 . 디스크 사용 정책에 맞게 기록할 적절한 위치에 대해 시스템 관리자에게 문의하고 로컬 시스템에서 완전히 벗어난 곳에 기록하는 것을 고려하십시오.

Answer 3

/tmp는 파일을 넣기에 편리한 장소일 뿐이며 상당히 확신할 수 있는 장소는 정리될 것입니다(예를 들어 웹 앱이 정리에 실패한 경우). 따라서 합리적인 기본값입니다.

파일을 업로드할 경로를 직접 지정할 수 있는 옵션이 있는 경우 최종 대상과 동일한 마운트에 경로를 만들 이유가 있습니다. 그러면 원자 이름 바꾸기를 사용하여 최종 경로에 넣을 수 있습니다. 장소. (크로스 마운트인 경우 복사본을 만들어야 합니다.)

(예를 들어) 업로드가 중간에 중단되면 거기에 부분 파일이 남을 수 있으므로 최종 대상에 업로드하지 않을 것입니다. 또는 스크립트가 종료되면 데이터베이스에서 참조하지 않는 고아 파일이 남을 수 있습니다.

참고: 클라이언트가 제공한 파일 이름은 신뢰할 수 없는 데이터라는 점을 기억하세요. 악의적인 사용자가 쉽게 파일 이름을 알려줄 수 ../../../something있으며, 조심하지 않으면 의도하지 않은 내용을 쓰게 될 수도 있습니다.