64MB 플래시 메모리가 3048MB에 도달할 수 있는 이유는 무엇입니까?

64MB 플래시 메모리가 3048MB에 도달할 수 있는 이유는 무엇입니까?

저는 64MB 플래시와 256MB RAM을 갖춘 Linux 기반 STB(셋톱박스)를 가지고 있습니다. 다른 이미지로 새로고침하기 전에 일부 설정을 백업하고 싶지만 정확히 어디에 있는지 모르겠습니다. 그건 나중에 조사해 볼 것 같아요. 그래서 FTP를 통해 상자에 연결하고 모든 파일과 폴더를 다운로드하기로 결정했습니다. FTP 클라이언트에서 상자의 루트를 마우스 오른쪽 버튼으로 클릭하고 Windows 바탕 화면의 전용 폴더에 다운로드하도록 선택했습니다.

다운로드는 계속되고 결코 멈추지 않는 것 같습니다. 그러나 FTP 서버에 의해 FTP 연결이 종료됩니다(로그에 그렇게 나와 있는 것 같습니다). 결국 2.97GB의 데이터가 생겼습니다. 어떻게 이럴 수있어? 이 데이터는 어디에서 오는가? ...256MB 이상을 저장할 수 없나요? ! ...

Linux 시스템의 루트 디렉터리를 즉시 복사하고 다른 모든 파일과 폴더도 복사될 것으로 기대할 수 없는 이유는 무엇입니까? 이것은 Windows에서 C:\를 복사하는 것과 동일하지 않습니까? 실시간 시스템이라서 그런걸까요? ...먼저 닫거나 로그아웃하고 프로세스를 중지해야 할까요? 그때는 대기모드였는데..

답변1

STB에 저장할 수 있는 것보다 더 많은 데이터를 전송하는 데는 최소한 3가지 이유가 있습니다.

  • 스파스 파일: 파일은 항상 파일의 시작 시간부터 현재 길이까지 연속적인 바이트 시퀀스를 포함하는 것으로 보입니다. 그러나 (보통 바이너리) 파일을 생성하고 특정 바이트 범위만 쓸 수 있습니다. 이 경우 이러한 바이트 범위 사이의 구멍(기록되지 않음)을 읽을 때 값이 0인 바이트가 포함된 것으로 나타납니다. 파일 시스템은 소프트웨어가 이러한 "취약성"을 생성할 때 이를 알아차리지만 실제로 이를 디스크에 저장하지 않습니다. 이 방법으로 1000000바이트 파일을 생성하고 999999 위치에 단일 바이트를 쓸 수 있습니다. 파일 크기는 거의 1MB이지만 디스크 공간은 한 블록만 차지합니다.

    파일 형식에서 파일의 일부 부분이 특정 바이트 오프셋에 있어야 하지만 모든 내용이 채워지지는 않는 경우 특정 유형의 데이터베이스 또는 인덱스 파일이 희박할 수 있습니다.

    파일 복제기는 파일이 시작 위치에서 희박하다는 것을 알 수 없으므로 소스에서 전체 파일을 바이트 스트림으로 읽고 동일한 바이트 스트림을 대상에 씁니다. 파일의 모든 바이트가 대상에 기록되므로 대상의 파일 시스템은 스파스 파일을 생성하지 않습니다.

    데이터 세트의 희소 파일로 인해 크기가 증가하는 것으로 의심되는 경우 --sparse다음 옵션을 시도해 보십시오.동기화. 소스에 값이 0인 바이트가 많을 때마다 대상에 희소 파일을 생성합니다. (소스 파일이 있는지 여부는 알 수 없습니다.실제로희박할 수도 있지만 어쨌든 목적지에서는 희소하게 됩니다. )

    STB에는 하나 이상의 스파스 파일을 사용하여 구현할 수 있는 일종의 내부 데이터베이스가 포함되어 있을 수 있습니다. 소스 파일 시스템에서 매우 큰 파일, 특히 STB의 저장 용량보다 큰 파일을 찾습니다. 그것들가지다희소해지다.

  • 항목이 여러 위치에 설치됩니다.. STB와 같은 임베디드 시스템은 제조업체의 소프트웨어 배포 및 사용자 데이터의 일부인 읽기 전용 파티션과 읽기/쓰기 파티션이 혼합되어 있을 수 있으므로 파일 시스템 레이아웃이 이상한 경우가 많습니다. 이는 Raw 플래시에서 다양한 유형의 파일 시스템용으로 설계되었습니다. (블록 장치가 아님), 부트로더 파티션, 매우 쉽게 공장 초기화 기능을 허용하는 공동으로 마운트된 파일 시스템, 램디스크(정전 시 파일 시스템을 손상시키지 않고 제대로 작동하기 위해) 등...따라서 실제 동일한 콘텐츠가 여러 다른 독립적인 위치에 설치될 수 있습니다(예: 공장 원본 형식, 공동 설치, 다른 목적을 위한 번들 설치 등).

    이 문제를 해결하려면 이 df명령이 도움이 될 수 있습니다. 하지만 일부 임베디드 시스템 제조업체에서는 출력에서 ​​수행 중인 작업이 명확하지 않을 정도로 이상한 작업을 수행합니다 df. 그러나 최소한 어떤 파일 시스템이 존재하고 각 파일 시스템이 얼마나 완전한지 확인할 수 있어야 합니다.

  • 하드 링크:FTP는 하드 링크를 인식하지 못하므로 동일한 파일에 두 개의 링크를 복사하도록 요청하면 파일을 두 번 복사하여 대상에서 두 배의 공간을 차지합니다. 파일에 2개 이상의 링크가 있는 경우 그에 따라 링크가 곱해집니다.

    이 문제를 해결하려면 rsync의 --hard-links옵션을 사용해 보세요.

세 가지 중 두 가지 경우에는 rsync를 사용하여 파일을 복사하는 것이 좋습니다. 이는 STB에 대한 셸 액세스 권한이 있고 rsync가 설치되어 있거나 설치할 수 있는 경우 또는 STB가 rsync를 파일 전송 프로토콜로 제공하는 경우에만 가능합니다(STB는 그렇지 않을 수도 있지만 일부 홈 NAS 장치에서는 제공).

사용할 수 있다면 rsync는 한 시스템에서 다른 시스템으로 대량의 데이터를 복사하는 좋은 방법입니다. 위의 세 가지 문제 중 두 가지(또는 세 가지 모두 참조 --one-file-system)를 선택적으로 해결할 수 있을 뿐만 아니라 중단된 복제를 재개하는 데도 매우 편리합니다.

답변2

Windows 측에서는 c:드라이브만 복사하는 것이 아니라 디스크 파일이 아닌 하드웨어 장치 등 다양한 파일을 복사하고 일부 파일을 여러 번 복사합니다. 전체 디스크 내용과 RAM의 여러 덤프를 포함할 수 있습니다.

Linux 및 기타 UNIX 계열 시스템에서는 거의 모든 것이 파일입니다. 일반 파일 및 디렉토리 외에도 다음이 있습니다.심볼릭 링크(다른 파일에 대한 포인터) 및장치 파일하드웨어 장치(디스크, 파티션, RAM, 직렬 포트 등)를 나타냅니다. 디스크에 저장되지 않지만 응용 프로그램이 시스템에 대한 데이터에 액세스할 수 있도록 하는 특수 파일 시스템도 있습니다./proc(프로세스)그리고/sys(시스템 파일 시스템).

장치에는 /dev심지어끝없는파일 – 영원히 읽을 수 있는 파일입니다. 예 /dev/zero, 여기에는 읽고 싶은 널 바이트가 얼마든지 포함되어 있습니다. 또한 /dev/urandom여기에는 읽고 싶은 임의의 수의 임의 바이트가 포함되어 있으므로 n 임의 바이트를 얻으려면 n 바이트를 읽어야 합니다 /dev/urandom.

FTP 프로그램을 사용하여 전체 파일 시스템 트리를 전송하는 경우 모든 것을 복사하고 에서 얻을 수 있는 만큼의 데이터를 복사 /proc하거나 에서 얻을 수 있는 만큼의 데이터를 복사할 가능성이 높습니다 /dev.

추가 자료:

FTP 외에 SSH 명령줄과 같이 장치에 연결하는 다른 방법이 있는 경우 FTP는 특수 파일을 인식하지 못하므로 FTP 대신 해당 방법을 사용하십시오. 명령을 실행하여 df존재하는 파일 시스템을 확인하십시오. 다음 명령을 사용하여 루트 파일 시스템을 백업할 수 있습니다.

rsync -a -x root@settopbox:/ settopbox.backup

(tell -x옵션 에 주목하세요.동기화이 프로그램은 파일 시스템에 걸쳐 있지 않습니다. )

루트 파일 시스템은 백업할 가치가 있는 시스템이 아닐 수 있으며, 일부 장치에는 읽기 전용 루트 파일 시스템이 설정되어 있고 설정이 포함된 다른 읽기-쓰기 파일 시스템이 있습니다. 명령의 출력을 게시 df하고 mount백업할 명령을 결정하는 데 도움이 필요한 경우.

또는 플래시 자체를 백업하세요. 장치 이름을 찾아야합니다. 블록 장치, 즉 디스크나 디스크 파티션에 해당하는 장치 또는 기타 유사한 장치를 찾으려면 다음 명령을 사용해 보십시오.

find /dev -type b
ls -l /dev /dev/* | grep '^b'

이러한 장치가 무엇을 의미하는지 확실하지 않은 경우 해당 명령의 출력을 게시하세요.

답변3

그 이유는 Linux에는 다음과 같은 프로그램이 있기 때문입니다.프로세스파일 시스템.

proc/proc커널 데이터 구조에 설치 되고 표현됩니다. 객체 중 하나는 /proc/kcore커널 메모리 코어의 바이너리 이미지입니다. 즉, 시스템에서 사용되는 모든 메모리가상 메모리 포함.

내 워크스테이션의 예는 다음과 같습니다.

$ cat /proc/meminfo | grep MemTotal
MemTotal:        3507728 kB
$ ls -lh /proc/kcore
-r-------- 1 root root 128T 2012-09-21 17:24 /proc/kcore

보시다시피 RAM은 4GB 밖에 없습니다. 비록 /proc/kcore거대하지만128TB! 이것은상당히나보다 더 많은(약 32,000배) 더 많은 메모리를 가지고 있습니다.

관련 정보