리눅스2013. 11. 25. 08:17

ext4 파일 시스템에 대한 커널 documentation에는 noauto_da_alloc에 대해서 다음과 같이 기술하고 있다.


auto_da_alloc(*)	Many broken applications don't use fsync() when 
noauto_da_alloc		replacing existing files via patterns such as
			fd = open("foo.new")/write(fd,..)/close(fd)/
			rename("foo.new", "foo"), or worse yet,
			fd = open("foo", O_TRUNC)/write(fd,..)/close(fd).
			If auto_da_alloc is enabled, ext4 will detect
			the replace-via-rename and replace-via-truncate
			patterns and force that any delayed allocation
			blocks are allocated such that at the next
			journal commit, in the default data=ordered
			mode, the data blocks of the new file are forced
			to disk before the rename() operation is
			committed.  This provides roughly the same level
			of guarantees as ext3, and avoids the
			"zero-length" problem that can happen when a
			system crashes before the delayed allocation
			blocks are forced to disk.


쉽게 풀어 얘기하자면, rename혹은 truncate같은 operation을 fsync()없이 행했을 경우, auto_da_alloc이 켜져 있으면 data=ordered 모드일 때, 다음 journal commit 시에 강제로 delayed 된 allocation 블럭들을 allocate 한다는 얘기다. (말이 쉽게 풀어 얘기지, 그냥 번역이네..)


따라서 ext3에 있던 "zero-length" 문제(delayed alloction 블럭이 disk에 쓰여지기 전에 시스템이 crash되는 문제)를 해결 할 수 있다.


noauto_da_alloc은 위와 같은 옵션을 꺼버리는 것이다.  이는 퍼포먼스 향상을 가져오지만 위에서 서술한 이점에 대해서는 포기하게 되는 것이다.

Posted by code cat
리눅스2013. 11. 24. 16:51


출처:http://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/writebarr.html

Chapter 16. Write Barriers

write barrier is a kernel mechanism used to ensure that file system metadata is correctly written and ordered on persistent storage, even when storage devices with volatile write caches lose power. File systems with write barriers enabled also ensure that data transmitted via fsync() is persistent throughout a power loss.
Enabling write barriers incurs a substantial performance penalty for some applications. Specifically, applications that use fsync() heavily or create and delete many small files will likely run much slower.

16.1. Importance of Write Barriers

File systems take great care to safely update metadata, ensuring consistency. Journalled file systems bundle metadata updates into transactions and send them to persistent storage in the following manner:
  1. First, the file system sends the body of the transaction to the storage device.
  2. Then, the file system sends a commit block.
  3. If the transaction and its corresponding commit block are written to disk, the file system assumes that the transaction will survive any power failure.
However, file system integrity during power failure becomes more complex for storage devices with extra caches. Storage target devices like local S-ATA or SAS drives may have write caches ranging from 32MB to 64MB in size (with modern drives). Hardware RAID controllers often contain internal write caches. Further, high end arrays, like those from NetApp, IBM, Hitachi and EMC (among others), also have large caches.
Storage devices with write caches report I/O as "complete" when the data is in cache; if the cache loses power, it loses its data as well. Worse, as the cache de-stages to persistent storage, it may change the original metadata ordering. When this occurs, the commit block may be present on disk without having the complete, associated transaction in place. As a result, the journal may replay these uninitialized transaction blocks into the file system during post-power-loss recovery; this will cause data inconsistency and corruption.

How Write Barriers Work

Write barriers are implemented in the Linux kernel via storage write cache flushes before and after the I/O, which isorder-critical. After the transaction is written, the storage cache is flushed, the commit block is written, and the cache is flushed again. This ensures that:
  • The disk contains all the data.
  • No re-ordering has occurred.
With barriers enabled, an fsync() call will also issue a storage cache flush. This guarantees that file data is persistent on disk even if power loss occurs shortly after fsync() returns.


'리눅스' 카테고리의 다른 글

sysroot  (0) 2014.03.14
[EXT4] noauto_da_alloc 옵션에 대해서  (0) 2013.11.25
[Mint Linux] gnome shell emulation  (0) 2012.09.08
우분투 remote 로 접속해서 X 서버 돌리기  (0) 2012.04.17
ext4분석  (0) 2012.04.10
Posted by code cat
리눅스2012. 4. 10. 15:43

다음의 글은 아래의 출처에서 가져왔음을 밝힌다.

출처:http://www.ibm.com/developerworks/kr/library/l-anatomy-ext4/



Linux 커널이 새롭게 발표될 때마다 몇 가지 뛰어난 기능이 포함되어 있듯이 이번 12월에 발표된 2.6.28 릴리스에도 우수한 기능이 포함되어 있다. 이 릴리스는 현재 개발 작업이 한창 진행 중인 Btrfs와 같은 여러 가지 우수한 기능 중에서 안정적인 ext4 파일 시스템이 최초로 적용된 릴리스이다. 이 차세대 Extended File System에서는 확장성과 신뢰성이 향상되었으며 뛰어난 새 기능도 추가되었다. Ext4는 1TB 디스크를 최대 백만 개까지 사용할 수 있는 파일 시스템으로 확장할 수 있다.

 

 

Extended File System의 약사


 

VFS(Virtual File System) 스위치

VFS는 상위 계층 파일 시스템 사용자의 기본 파일 시스템에 대한 세부 사항을 추상화하는 계층이다. 이러한 기능을 제공하는 VFS를 바탕으로 Linux는 지정된 Linux 시스템에서 여러 파일 시스템을 동시에 지원할 수 있다.

 

Linux를 지원하는 최초의 파일 시스템은 Minix 파일 시스템이었지만 이 파일 시스템에는 몇 가지 심각한 성능 문제가 있었기 때문에 Extended File System이라는 파일 시스템이 Linux를 위해 특별히 개발되었다. Remy Card가 설계한 첫 번째 Extended File System(ext)은 1992년 4월에 Linux에 채택되었다. ext 파일 시스템은 0.96c 커널에 구현된 VFS(Virtual File System) 스위치를 최초로 사용했으며 최대 2GB 크기의 파일 시스템을 지원했다.

 

두 번째 Extended File System(ext2) 또한 Remy Card가 구현했으며 1993년 1월에 발표되었다. 이 파일 시스템은 Berkeley FFS(Fast File System)와 같은 당시의 다른 파일 시스템의 발전된 아이디어를 채택했다. Ext2에서는 지원되는 파일 시스템의 크기가 2TB로 확장되었으며 2.6 커널에서는 ext2 파일 시스템의 최대 크기가 32TB로 확장되었다.

 

세 번째 Extended File System(ext3)은 일부 경쟁 파일 시스템에 비해 성능이 떨어지기는 했지만 Linux 파일 시스템의 맥락에서는 크게 발전한 모습을 보여 준 파일 시스템이다. ext3 파일 시스템에서는 예기치 않게 시스템이 중단되었을 때 파일 시스템의 신뢰성을 높여 주는 저널링 개념이 도입되었다. Silicon Graphics의 XFS 및 IBM® JFS(Journaled File System)와 같은 경쟁 파일 시스템의 성능이 더 좋기는 했지만 ext3은 이미 ext2를 사용하고 있는 시스템에서 직접 업그레이드할 수 있는 기능을 지원했다. Ext3은 2001년 11월에 발표되었으며 Stephen Tweedie가 구현했다.

현재, 네 번째 Extended File System(ext4)이 발표되었다. Ext4에는 성능, 확장성 및 신뢰성을 향상시킨 수많은 새 기능이 도입되었다. 가장 눈에 띄는 특징은 ext4가 1EB(exabyte)의 파일 시스템을 지원한다는 것이다. Ext4는 ext3를 유지 관리해 온 Theodore Tso가 이끄는 개발자 팀에 의해 구현되어 2.6.19 커널에 채택되었다. 그리고 지금은 2.6.28 커널에 이르러 안정적인 상태로 유지되고 있다(2008년 12월 현재).

Ext4에는 다양한 경쟁 파일 시스템의 유용한 개념이 적용되었다. 예를 들어, 익스텐트를 사용하여 블록을 관리하는 방법은 JFS에서 구현했으며 또 다른 블록 관련 기능인 지연된 할당은 XFS와 Sun Microsystems의 ZFS에서 구현했다.

새로운 ext4 파일 시스템에서는 혁신적으로 개선된 다양한 기능을 볼 수 있다. 새롭게 추가된 기능, 현재 파일 시스템의 한계를 뛰어 넘은 우수한 확장성, 오류에 효과적으로 대응할 수 있는 신뢰성 및 뛰어난 성능에 이르기까지 파일 시스템의 모든 부분에서 개선된 사항을 발견할 수 있다.


Ext4에는 새 기능이 매우 많이 포함되어 있기는 하지만 그 중에서도 가장 중요한 특징은 이전 버전인 ext3과의 쌍방 호환성이며 앞으로 더 높은 성능을 제공하게 될 미래의 Linux 시스템을 내다보고 시간 소인의 기능도 향상되었다.

이전 버전 및 후속 버전과의 호환성

ext3은 오늘날 Linux에서 가장 많이 사용되고 있는 파일 시스템 중 하나이기 때문에 ext4로의 마이그레이션은 큰 어려움 없이 쉽게 수행할 수 있어야 한다. 이를 위해 ext4는 쌍방 호환성을 고려하여 설계되었다(그림 1 참조). Ext4는 ext3 파일 시스템을 ext4 파일 시스템으로 마운트할 수 있도록 후속 버전으로의 호환성을 제공한다. ext4를 충분히 활용하려면 파일 시스템 마이그레이션을 수행하여 새로운 ext4 형식으로 변환한 후 사용해야 한다. ext4 파일 시스템을 ext3로도 마운트할 수 있기는(이전 버전과의 호환성) 하지만 ext4 파일 시스템에서 익스텐트(성능 섹션 참조)를 사용하지 않는 경우에만 가능하다.


그림 1. ext4의 쌍방 호환성

 


이러한 호환성 특징 외에도 ext3 파일 시스템을 ext4로 마이그레이션하는 작업을 점차적으로 수행할 수 있다. 즉, 옮기지 않은 기존 파일을 기존 ext3 형식으로 유지하면서 새 파일(또는 복사한 기존 파일)을 새로운 ext4 데이터 구조로 관리할 수 있다. 이러한 방법을 통해 온라인으로 ext3 파일 시스템을 ext4 파일 시스템으로 마이그레이션할 수 있다.

 

시간 소인 정밀도 및 범위 향상

 

놀랍게도 ext4 이전의 Extended File System에서는 초 단위의 시간 소인을 사용하고 있다. 이 시간 소인은 많은 설정에서 효과적으로 사용되었지만 프로세서의 처리 속도가 빨라지고 통합 기능(멀티 코어 프로세서)이 향상되었을 뿐만 아니라 고성능 컴퓨팅과 같은 다른 애플리케이션 도메인에서 Linux가 사용되면서 그 한계가 드러나고 있다. Ext4의 시간 소인은 기본적으로 나노초 LSB로 확장되어 후속 버전과의 호환성을 보장한다. 또한 두 개의 추가 비트를 통해 시간 범위도 500년 이후까지 사용할 수 있도록 확장되었다.


확장성

 

업그레이드할 파일 시스템의 가장 중요한 특성 중 하나는 증가하는 수요에 대응할 수 있는 확장성이다. 여러 가지 방법으로 확장성을 강화한 Ext4는 ext3 한계를 극복하고 파일 시스템 메타데이터 관리를 위한 토대를 새롭게 마련하였다.

 

파일 시스템 제한 확장

 

ext4의 첫 번째 가시적인 차이점은 파일 시스템 볼륨, 파일 크기 및 서브디렉토리 제한에 대한 지원이 향상되었다는 것이다. Ext4는 최대 1EB(1000PB)의 파일 시스템을 지원한다. 오늘날 적용되고 있는 표준에 따르면 많은 용량처럼 보이기는 하지만 스토리지 사용량이 지속적으로 늘어나고 있다는 점을 감안하면 ext4가 미래를 염두에 두고 개발되었음을 명확히 알 수 있다. ext4에서 허용되는 최대 파일 크기는 16TB(4KB 블록 가정)이며, 이는 ext3의 최대 파일 크기의 8배에 해당한다.

마지막으로 ext4에서는 서브디렉토리 제한도 32KB 디렉토리 깊이에서 거의 무한대로 확장되었다. 이러한 확장이 무리한 확장으로 보인다면 1EB의 스토리지를 사용하는 파일 시스템의 계층 구조를 생각해 봐야 한다. 디렉토리 인덱싱도 해시된 B 트리 형태의 구조로 최적화되었다. 따라서 제한이 크게 확장되었음에도 불구하고 ext4에서는 매우 빠른 조회가 가능하다.

 

익스텐트

 

ext3의 주요 단점 중 하나는 할당 방법에 있었다. 여유 공간에 대한 비트 맵을 통해 파일이 할당되었는데 이 방법은 빠르지도 않고 확장성도 좋지 않았다. Ext3의 형식은 작은 파일에 매우 효율적이지만 큰 파일에는 비효율적이다. Ext4에서는 할당 기능을 향상시키고 더욱 효율적인 스토리지 구조를 지원하기 위해 ext3의 메커니즘을 익스텐트로 대체했다. 익스텐트는 연속되는 블록 시퀀스를 나타낸다. 이처럼 익스텐트를 사용하게 되면 블록의 저장 위치에 대한 정보를 유지하는 대신 연속 블록으로 구성된 긴 목록의 저장 위치에 대한 정보가 유지되기 때문에 저장되는 전체 메타데이터의 용량이 줄어든다.

ext4의 익스텐트는 계층화된 접근 방법을 통해 작은 파일을 효율적으로 나타내며 익스텐트 트리를 사용하여 대용량 파일을 효율적으로 나타낸다. 예를 들어, 단일 ext4 inode에는 4개의 익스텐트를 참조할 수 있는 공간이 있으며, 이 경우 각 익스텐트는 연속 블록 세트를 나타낸다. 대용량 파일(조각화된 파일 포함)의 경우, inode는 인덱스 노드를 참조할 수 있으며, 각각의 인덱스 노드는 여러 익스텐트를 참조하는 리프 노드를 참조할 수 있다. 이 고정 깊이 익스텐트 트리는 대용량 스파스 파일에 대한 효과적인 표현 스키마를 제공한다. 또한 노드에는 파일 시스템 손상을 방지하기 위한 자동 검사 메커니즘이 있다.


성능

새 파일 시스템을 측정하는 데 사용되는 가장 중요한 속성 중 하나는 기본 성능이다. 성능은 가장 어려운 분야 중 하나이다. 왜냐하면 파일 시스템의 용량이 커지고 신뢰성에 대한 기대가 높아질수록 성능 저하가 발생할 수 있기 때문이다. 하지만 ext4는 확장성과 신뢰성을 제공하는 동시에 성능 향상을 위한 여러 가지 향상된 기능도 제공한다.

 

파일 레벨 사전 할당

 

데이터베이스 또는 컨텐츠 스트리밍과 같은 특정 애플리케이션에서는 드라이브에 대한 순차 블록 읽기 최적화를 사용하고 블록에 대한 읽기 명령 비율을 최대화하기 위해 연속 블록에 저장되는 파일을 사용한다. 연속 블록 세그먼트를 제공할 수 있는 익스텐트 외에도 과거에 XFS에서 구현되었던 대로 매우 큰 연속 블록 섹션을 원하는 크기로 사전 할당하는 매우 강력한 방법도 있다. Ext4에서는 지정된 크기의 파일을 사전 할당 및 초기화하는 새로운 시스템 호출을 통해 이 기술이 구현되었다. 그런 다음 필요한 데이터를 기록한 후 데이터에 대한 제한적인 읽기 성능을 제공할 수 있다.

 

블록 할당 지연

 

할당 지연은 파일 크기를 기반으로 하는 또 하나의 최적화 방법이다. 이 성능 최적화 방법은 블록을 디스크에 강제로 기록할 때까지 디스크의 물리적 블록을 할당하지 않고 기다린다. 이 최적화 방법의 핵심은 디스크에 기록할 필요가 있을 때까지 물리적 블록의 할당이 지연되기 때문에 더 많은 블록을 연속 블록에 할당 및 기록할 수 있다는 것이다. 이 방법은 파일 시스템에서 작업이 자동으로 수행된다는 점을 제외하면 지속적인 사전 할당과 유사하다. 하지만 파일 크기가 미리 알려져 있는 경우에는 지속적인 사전 할당이 가장 효과적인 방법이다.

 

멀티 블록 할당

 

최적화를 위해 향상된 마지막 기능은 ext4의 블록 할당자이다. 이 최적화 방법 또한 연속 블록과 관련되어 있다. ext3의 경우 블록 할당자는 한 번에 하나의 블록을 할당하는 방식으로 작동한다. 여러 개의 블록이 필요한 경우 연속 데이터를 연속되지 않은 블록에서 찾을 수 있었다. Ext4에서는 디스크에 연속되어 있을 수 있도록 여러 블록을 동시에 할당하는 블록 할당자를 사용하여 이 문제를 해결했다. 이전 최적화와 마찬가지로 이 최적화에서도 순차 읽기 최적화를 위해 디스크에서 최적화할 관련 데이터를 수집한다.

 

멀티 블록 할당의 또 다른 특징은 블록을 할당하는 데 필요한 처리 리소스의 용량에서 찾아볼 수 있다. 한 번에 하나의 블록만을 할당하는 가장 단순한 형태의 방법을 사용하는 ext3의 경우에는 블록 할당을 수행하기 위해 블록마다 한 번의 호출이 필요했다. 하지만 여러 블록을 동시에 할당하는 경우에는 블록 할당자에 대한 호출 횟수가 많이 줄어들기 때문에 할당 속도가 빨라지고 필요한 처리 리소스의 양도 줄어든다.


 

ext4에서는 파일 시스템이 매우 큰 크기로 확장될 수 있기 때문에 신뢰성에 대한 관심도 당연히 커질 것이다. Ext4에는 이러한 우려를 해소할 수 있는 여러 가지 자동 보호 및 자동 복구 메커니즘이 마련되어 있다.

 

파일 시스템 저널에 대한 체크섬 검사

 

ext3과 마찬가지로 ext4도 저널링 파일 시스템이다. 저널링저널(디스크의 연속된 영역에 있는 전용 순환 로그)을 통해 파일 시스템의 변경 사항을 기록하는 프로세스이다. 그런 다음 로그에 기록된 변경 사항에 따라 물리적 스토리지에 실제 변경 사항이 적용된다. 이 방법을 사용하면 좀 더 안정적으로 변경 사항을 구현할 수 있으며 작업 중에 시스템 오류 또는 전원 문제가 발생하더라도 일관성을 유지할 수 있다. 결과적으로 파일 시스템의 손상 가능성이 줄어드는 효과를 얻을 수 있다.

저널링을 사용하더라도 올바르지 않은 항목이 저널에 있다면 손상 가능성은 여전히 존재한다. 이 문제를 해결하기 위해 ext4에서는 저널에 대한 체크섬 기능을 구현하여 올바른 변경 사항만 기본 파일 시스템에 적용되도록 보장한다. 참고자료 섹션에서 ext4의 중요한 기능인 저널링에 대한 추가 참고자료를 볼 수 있다.

Ext4는 사용자의 필요에 따라 여러 가지 모드의 저널링을 지원한다. 예를 들어, ext4는 메타데이터만 저널링되는 모드(Writeback 모드), 메타데이터가 저널링된 후 저널을 바탕으로 메타데이터가 기록될 때 데이터가 기록되는 모드(Ordered 모드) 및 메타데이터와 데이터가 모두 저널링되는 모드(가장 안정적인 Journal 모드)를 지원한다. Journal 모드는 파일 시스템의 일관성을 보장하는 가장 좋은 방법이기는 하지만 모든 데이터가 저널을 통과하기 때문에 가장 느린 방법이기도 하다.

 

온라인 조각 모음

 

ext4에는 파일 시스템 내의 조각을 줄여 주는 기능(순차 블록 할당을 위한 익스텐트)이 통합되어 있기는 하지만 파일 시스템을 장기간 사용할 경우에는 어느 정도의 조각이 발생하는 것은 피할 수가 없다. 이 문제를 해결하여 성능을 향상시키기 위해 파일 시스템 및 개별 파일에 대한 조각 모음을 수행하는 온라인 조각 모음 도구가 제공된다. 온라인 조각 모음 도구는 인접한 익스텐트를 참조하는 새 ext4 inode에 파일을 복사하는 단순한 도구이다.

온라인 조각 모음의 또 다른 특징은 파일 시스템 검사(fsck)에 필요한 시간이 짧다는 것이다. Ext4에서는 inode 테이블에 있는 블록 그룹 중 사용되지 않고 있는 블록 그룹이 구별되기 때문에 fsck는 해당 블록 그룹 전체를 생략하여 빠르게 검사 프로세스를 수행할 수 있다. 파일 시스템의 크기가 증가하게 되면 필연적으로 내부 손상이 발생하기 마련이며 이러한 문제를 해결하기 위해 운영 체제는 파일 시스템에 대한 유효성 검증을 수행한다. 그리고 이러한 유효성 검증을 통해 ext4가 전반적으로 높은 신뢰성을 갖추고 있음을 알 수 있다.


미래의 모습

 

Extended File System은 분명 1992년에 처음 발표된 ext부터 2008년의 ext4에 이르기까지 Linux 내에서 길고도 의미 있는 역사를 가지고 있다. Linux를 위해 특별히 설계된 첫 번째 파일 시스템이면서 가장 효율적이고, 안정적이며 강력한 파일 시스템 중 하나였음을 입증해 보였다. XFS, JFS, Reiser 및 IRON 결함 허용 파일 시스템 기술 등의 다른 새 파일 시스템의 아이디어도 통합되어 있는 Ext4는 파일 시스템 관련 리서치에서 꾸준한 발전을 보여 주고 있다. 앞으로 개발될 ext5의 모습을 예측하기에는 너무 앞선 감이 있지만 엔터프라이즈 환경을 대비한 Linux 시스템을 이끌게 될 것이라는 점만은 분명하다.


참고자료

교육

제품 및 기술 얻기

  • kernel.org에서 최신 커널 릴리스를 다운로드할 수 있다.

  • developerWorks에서 직접 다운로드할 수 있는 IBM 시험판 소프트웨어를 사용하여 Linux와 관련된 후속 개발 프로젝트를 구현해 볼 수 있다.

토론

필자소개

M. Tim Jones

M. Tim Jones는 임베디드 펌웨어 아키텍트이자 Artificial Intelligence: A Systems Approach, GNU/Linux Application Programming(현재 2판), AI Application Programming(현재 2판) 및 BSD Sockets Programming from a Multilanguage Perspective의 저자이다. 정지 위성을 위한 커널 개발에서 시작해 임베디드 시스템 아키텍처와 네트워크 프로토콜 개발에 이르기까지 다양한 분야에 대한 공학 지식을 가지고 있다. 콜로라도주 롱몬트 소재의 Emulex Corp.에서 컨설턴트 엔지니어로 활약하고 있다.

      


Posted by code cat
리눅스2012. 3. 18. 14:36

예전에 ext4파일 시스템 굽기에 대해서 적은 글에 대해서 지금와서 생각해보니 나름대로 용도가 있겠지만, 그 당시에 필요했던 용도로 쓰기엔 매우 불편한 방법이었다.

그래서 더 쉬운 방법이 생각났는데, 그거슨..


/dev/sda1 등으로 되어있는 디바이스 파일을 통째로 덤프를 떠서 bin파일로 만든 뒤에 이를 mount시키면 되는 것이다.
덤프를 뜨는 방법은 뭐 간단히 cat을 써도 되고, 프로그램을 하나 만들어서 읽어써 쓰는 작업을 해도 되겠다.

실제로 해보니 너무 간단히 되어 버려서 허탈했다.
그러나 위에서 말했듯이, dd를 사용해서 쓰는 방법도 나름 쓸모가 있다. 예를 들면 원하는 크기의 ext4파일 시스템을 빈 상태로 설정해 준다던가.. 어쨌든 알아두면 유용하게 쓰일 일이 있다.
Posted by code cat
리눅스2011. 8. 17. 14:21
출처: http://www.novell.com/support/search.do?cmd=displayKC&sliceId=SAL_Public&externalId=3907838
 

JBD: barrier-based sync failed on mmcblkxxx -diabling barriers

JBD = 저널링 블록 디바이스
이 메세지를 끌라면, barrier=off 라는 매게변수를 커널에 넘겨주면 된다. GRUB의 경우에는 /boot/grub/menu.lst에 넣으면 되겠다.  이렇게 하면 커널은 transaction barrier 메카니즘을 사용하지 않게된다.

기본적으로 리눅스 커널은 transaction barrier를 사용하는데, 이는 데이터의 보전성을 유지하기 위한 부가적인 메카니즘이다.
많은 저장 서브시스템은 data의 write 퍼포먼스를 높이기 위해 캐시나 쓰는 order를 변경하는데, 이는 저널링 파일 시스템안에서 관리되는 저널된 데이터에겐 좋지 않다.  저널링은 실제 데이터가 쓰여지기 전에 메타데이터를 씀으로서 크래시 리커버리를 구현한다.  위의 에러(?) 메세지는 그러한 transaction barrier를 지원하지 않는다는 소리이며, 전혀 해로울것은 없지만, barrier는 일반적으로 퍼포먼스를 높여준다.

Posted by code cat
리눅스2011. 8. 2. 20:39
dd if=/dev/zero of=ext4.img bs=1MB count=20  // 20mb 짜리 ext4.img라는 파일을 생성

mke2fs -T ext4 ext4.img  //ext4 타입으로 ext4.img를 포맷


mkdir test //테스트용 디렉토리 생성(마운트 포인트로 이용)

mount -t ext4 -o loop ext4.img test/   //마운트

마운트가 성공됬으면(mount 커맨드로 확인), 테스트로 파일을 막 써보자.
cd test
touch TEMPFILE
mkdir BABO
...

파일이 제대로 생성됐는지 확인해보고, 언마운트를 해보자
cd ..  //test 폴더 안에서 언마운트 할라면 device busy라고 불평한다.
umount /dev/loop0  //꼭 loop0이라는 보장은 없고 아마 마운트시 available한 loop이 잡히는 걸로 안다.
                             //이 부분은 losetup으로 체크할 수 있는 걸로 안다.
cd test/
ls -al 로 확인하면 텅 빈 걸 확인할 수 있다.

다시 마운트 해보자.
mount -t ext4 -o loop ext4.img test/ 
ls -al
해보면 아까 테스트로 막 만든 파일들이 보인다.

자 그럼 이걸 가지고 뭐에 써먹냐 ?  ext4.img 자체를 파티션에 그대로 구울 경우, ext4파일 시스템을 가진 루트파일 시스템 등을 구축 할 수 있는 것이다.  EXT4f라고 썼지만 다른 파일 시스템도 이렇게 해서 굽는게 가능하다.  물론 안드로이드용 파일 시스템을 만들 땐 이걸 안 썼다. 언제 저 짓해서 맨날 구워줄 수 있단 말인가?  다른 방법에 대해서는 다음 기회에~
Posted by code cat

dd if=/dev/zero of=ext3.image bs=1MB count=1024

포맷에 따라서 파일을 복사하거나 변환시킴(주로 빈 파일 만들거나, loopback 디바이스 만들 때 사이즈 할당 시켜서 파일 만들 때 씀)

if=FILE
표준 입력 대신 파일로부터 읽어들인 파일
of=FILE
표준아웃으로 대신 파일로 씀
bs=BYTES
          ibs랑 obs를 BYTES로 강제 설정
count=BLOCKS
BLOCKS 만큼의 입력 블록을 복사함.

더 많은 정보는 http://linux.die.net/man/1/dd

 

'리눅스 > 스크립트/유틸' 카테고리의 다른 글

우분투 사용자 추가  (0) 2012.02.24
tar: time stamp s in the future  (0) 2011.08.26
tee 커맨드  (0) 2011.06.19
엔디안 처리하는 함수  (0) 2011.06.06
busybox cross-compile  (0) 2011.06.01
Posted by code cat