파일 삽입 syscall이없는 이유

필자가 이해하기 위해 파일을 조작하기 위해 Linux에는 sys_write syscall 만 있으며 파일 내용을 덮어 씁니다 (또는 끝날 경우 확장).

Linux에서 파일에 내용을 삽입하거나 삭제하기위한 syscall이없는 이유는 무엇입니까?

모든 현재 파일 시스템에서 파일을 연속 메모리 블록에 저장하지 않아도되므로 효율적인 구현이 가능해야합니다. (파일이 조각 날 것입니다.)

"쓰기시 복사"또는 "투명한 파일 압축"과 같은 파일 시스템 기능을 사용하면 현재 내용을 삽입하는 방법이 매우 비효율적 인 것 같습니다.

files file-copy system-calls

— 더 콜라 만
소스

모든 멋진 파일 작업과 마찬가지로 이러한 작업은 실제보다 훨씬 덜 유용합니다. 이러한 것의 주요 용도는 데이터베이스, 에뮬레이터 등과 같은 매우 특수한 응용 프로그램입니다. 일반적으로 파일을 "편집"하는 방법은 새 파일을 만들고 사용자가 새 파일의 이름을 이전 파일로 "저장"하는 것입니다.

— mosvy 2016 년

@mosvy, 그러나 "새 파일을 만든 다음 이름을 바꾸십시오"라는 개념은 그 자체로는 좋거나 시스템이 더 나은 방법을 제공하지 않기 때문에 사용됩니까? 특히 "이 행 수정 (길이 변경)"또는 "이 행 삽입"과 같은 텍스트 파일 작업은 일반적이므로 해당 기능에 대한 파일 시스템 작업이 사용 된 것으로 가정 할 수 있습니다. 물론, 그것들을 갖지 않으면 fs 구현이 훨씬 간단 해집니다.

— ilkkachu

@meuh OpenVMS는 여전히 RMS (레코드 관리 서비스)를 통해 수행됩니다.

— RonJohn

UNIX 는 파일 시스템 내부에서 레코드 관리 시스템을 제공 하지 않기 시작했습니다 .

— user207421 2016 년

@ilkkachu 그것은 그 자체로 훌륭하고 절대 의심의 여지가 없습니다 ;-) 더 많은 경우, inode가 불변이라면 블록 공유, 버전 관리 및 거의 모든 것을 훨씬 더 효율적으로 (그리고 추론하기가 훨씬 간단 하게) 구현할 것 입니다. 모든 스크립트 언어가 변경 불가능한 문자열로 전환 한 방식을 유추하여 생각해보십시오. 파일 시스템에 대해 커프를 말하기가 어렵고 like 소리처럼 들리지 않습니다. ;-)

— mosvy

답변:

실제로 가능한 리눅스 블록 에서는 바이트 단위가 아니라 일부 파일 시스템 (ext4 및 xfs)에서만 블록 (4096의 대부분 )이 가능합니다.

fallocate(2)맨 페이지 에서 인용 :

int fallocate(int fd, int mode, off_t offset, off_t len);

[...]

파일 공간 축소

FALLOC_FL_COLLAPSE_RANGE플래그 (Linux 3.15부터 사용 가능)를 지정하면 mode구멍을 남기지 않고 파일에서 바이트 범위 가 제거됩니다. 축소 될 바이트 범위는 바이트에서 시작하여 offset계속 len 됩니다. 작업이 완료되면 해당 위치에서 시작하는 파일의 내용이 location에 offset+len추가되고 offset파일의 len바이트가 줄어 듭니다.

[...]

파일 공간 늘리기

FALLOC_FL_INSERT_RANGE플래그 (Linux 4.1부터 사용 가능)를 지정하면 mode기존 데이터를 덮어 쓰지 않고 파일 크기 내에 구멍을 삽입하여 파일 공간을 늘립니다. 구멍은 시작하여 바이트 동안 offset계속 len됩니다. 파일 내부에 구멍을 삽입하면 시작하는 파일의 내용이 바이트 단위 offset로 위로 이동합니다 (즉, 더 높은 파일 오프셋으로 이동) len. 파일 안에 구멍을 삽입하면 파일 크기가 len바이트 단위로 증가합니다 .

— 이끼
소스

"그러나 바이트 단위가 아닌 블록 (4096)이있는" -4KiB 블록은 ext4에서 매우 일반적이지만 보장되지는 않습니다. Ext4 는 1KiB, 2KiB 및 4KiB 블록 크기를 지원합니다 . 그리고 ext2 일부터 알파 프로세서에서 8KiB도 지원되었다는 것을 기억합니다. 블록이 4KiB라고 가정 할 수는 없습니다.

— marcelm 2016 년

4k (기본값)는 1k와 2k의 배수이므로 4k를 ext4로 가정해도 아무런 문제가 없습니다. xfs도 기본적으로 4k로 설정되지만 4k보다 큰-최대 64k의 bs를 지원해야하지만 이러한 fs 만 만들 수 있었지만 ENOSYS가 없으면 마운트가 실패합니다. 어쨌든, 당신은 아무것도 가정 할 수 없습니다-이 기능은 모든 fs에서 지원되지 않으므로 block = 4096이라고 말하는 것이 좋습니다. 따라서 독자는 플로팅하고 사람들이 무엇이든 할 수있게하는 대신 비율이 있습니다. 또는 더 나쁜 것은 512 바이트이거나 vm 페이지 크기와 관련이 있다는 것입니다.

— mosvy 2016 년

편집 한 후 ( 일반적으로 4KiB 라고 말한 경우 ) 동의합니다. 내 문제는 이전에는 "블록은 항상 4KiB" 로 쉽게 읽 히게 되어 사람들이 그러한 가정을하고 버그가있는 코드를 작성할 수 있다는 점이었습니다.

— marcelm

모든 현재 파일 시스템에서는 파일을 연속 메모리 블록에 저장하지 않아도되므로

파일 시스템은 파일을 연속 영역에 저장하지 않아도 될 수 있지만 실제로는 매우 융통성이 없습니다. 그러나 일반적으로 파일은 고정 크기 블록 (또는 연속 블록 시퀀스)에 저장됩니다. 그렇게하면 구현이 간단 해지며 블록은 대개 기본 장치의 블록 크기의 배수입니다.

따라서 임의 길이의 블록 삽입을 구현하면 파일 시스템 형식과 구현이 다소 복잡해 지거나 잠재적으로 많은 양의 데이터를 이동해야합니다. 이들 중 어느 것도 실제로 좋지 않으며 파일 시스템 API 위에 사용자 공간에 복잡한 데이터 구조를 구축 할 수 있습니다.

— 일 카추
소스