'cramfs'에 해당되는 글 2건

  1. 2009.02.19 cramfs : Error -3 while decompressing!
  2. 2009.02.18 cramfs - Compressed RAM File System
Linux2009. 2. 19. 15:26
cramfs 는 일반적으로 MTD 기반 임베디드 리눅스에서 사용되는데, 검색을 해보니

  1. 되도록이면 root filesystem(루트 파일 시스템)으로는 cramfs 보다는 ext2나 jffs를 추천을 하고,
  2. 압축 해제에 관련된 오류 인데, 원본 파일이 이상이 있거나
  3. 압축 해제를 위한 메모리에 문제가 있다
는 식의 뭉떵거려진 대답뿐이었다.

위에 상황에서 2번을 조금 특화 시킨 문제로는
  1. 롬 라이터가 제대로 write를 하지 못한다.
  2. 롬 라이터는 제대로 write했으니 보드에서 제대로 읽지 못한다 - 특정 번지 이상을 잘못 읽음
이 있다.

특정 메모리를 못 읽는 상황은,
플래시의 Address 핀의 결선이 잘못 되어 특정 번지 이상을 읽지 못하는 경우이다.
Posted by 구차니
Linux2009. 2. 18. 18:42
요즘에는 잘 안쓰게 된 녀석이긴한데.. 아무튼 제약 사항은 다음과 같다.

Usage Notes
-----------

File sizes are limited to less than 16MB.

Maximum filesystem size is a little over 256MB.  (The last file on thefilesystem is allowed to extend past 256MB.)

Only the low 8 bits of gid are stored.  The current version of mkcramfs simply truncates to 8 bits, which is a potential security issue.

Hard links are supported, but hard linked files will still have a link count of 1 in the cramfs image.

Cramfs directories have no `.' or `..' entries.  Directories (like every other file on cramfs) always have a link count of 1.  (There's no need to use -noleaf in `find', btw.)

No timestamps are stored in a cramfs, so these default to the epoch (1970 GMT).  Recently-accessed files may have updated timestamps, but the update lasts only as long as the inode is cached in memory, after which the timestamp reverts to 1970, i.e. moves backwards in time.

Currently, cramfs must be written and read with architectures of the same endianness, and can be read only by kernels with PAGE_CACHE_SIZE == 4096.  At least the latter of these is a bug, but it hasn't been decided what the best fix is.  For the moment if you have larger pages you can just change the #define in mkcramfs.c, so long as you don't
mind the filesystem becoming unreadable to future kernels.

[출처 : cramfs 소스중 README 파일]


Posted by 구차니