[아래내용은 http://d.hatena.ne.jp/mir/20060825/p1 사이트에서 인용 하였습니다]

Buffer로서도 File로서도, 영역확보 시에 반드시 Access 단위(Page Size 혹은 Sector Size) 1개분 여분을 취득해서, align합니다.
Oracle은 Parameter 혹은 무언가로 설정해서 사용한다는 이야기가 있습니다만(추후 확인), InnoDB의 경우는 이러한 User측의 제어 방법은 없고, Raw Device를 사용여부에 관계없이, Raw Device를 사용하고 있어서 문제없는Code가 실행 됩니다.

Raw Device를 다시 집어보면 Kernel의 IO Buffer를 우회하여 Device에 대해 직접적인 Read/Write를 행하기 위해, Kernel이 Application에게 제공하는 Service 구조라고 할까요.

http://www.linux.or.jp/JF/JFdocs/SCSI-2.4-HOWTO/rawdev.html
http://www.linux.or.jp/JM/html/util-linux/man8/raw.8.html

스스로 Buffering을 하는 Software의 경우, 이 경우가 Overhead가 줄고, “ACID를 위한 동기 Write가 필요”한 경우에 더욱 편리하다고 하네요. (fsync ?)

http://www.atmarkit.co.jp/flinux/rensai/watch2005/watch06b.html

Raw Device가 장래 Linux에서 사라질지 모른다라는 “System Call Open시에 O_DIRECT를 지정하기 위해 Source Code를 바꿔 써야할 필요가….”
만약 그렇게 되면 InnoDB도 Source를 수정하지 않으면 안된다는.. O_RDWR지정 뿐이므로 (O_RDWR ? )

http://dev.mysql.com/doc/refman/5.0/en/innodb-raw-devices.html

You can use raw disk partitions as data files in the shared tablespace. By using a raw disk, you can perform non-buffered I/O on Windows and on some Unix systems without filesystem overhead, which may improve performance.

http://dev.mysql.com/doc/refman/5.0/en/innodb-tuning.html

When using the InnoDB storage engine with a large innodb_buffer_pool_size value on any release of Solaris 2.6 and up and any platform (sparc/x86/x64/amd64), a significant performance gain can be achieved by placing InnoDB data files and log files on raw devices or on a separate direct I/O UFS filesystem (using mount option forcedirectio; see mount_ufs(1M)). Users of the Veritas filesystem VxFS should use the mount option convosync=direct.

Question or Comment

1. InnoDB의 O_DIRECT 대응은 innodb_flush_method=O_DIRECT
    Response가 느려지는 결과가 초래... (Many Practice)
2. Raw Device를 사용하면 InnoDB의 성능이 향상 되는가?
    Disk Access에 걸리는 시간의 대부분은 Disk Access입니다. (Memory로의 Copy나, Cache Searching등은 상당히 적은 시간으로, Disk Access의 시간은 기본적으로 Paging와 Read/Write Transfer 시간입니다.

Read/Write Transfer는 어쩔 수 없는 부분이고, Paging를 전체적인 시야로 어떻게 줄이느냐가 성능을 향상시키는 중요한 Point 입니다.)

Linux 2.6 Kernel에서는 Paging하고 Disk Access할 때에 가능한 한 Data의 물리적배치순으로 Request를 재배치하고 Disk Access를 실행합니다. (어떤 Timing에 그걸 실행 할 지는 elevator= 등의 지정에 의함) 그러므로, Local Device등과 같은 Sequential Access 위주의 IO Type에 강한 Device에서는 Head의 이동이 최소한으로 제어할 수 있습니다. 또, 고가의 RAID Storage에서는 스스로 이와 같은 Access를 수정해 주기때문에 Buffering 여부와 관계없이 그 차이는 거의 없다고 볼 수 있습니다. 즉, OS의 Buffering를 Skip하고 Disk Access를 하면, Local Device등이 느려질 가능성이 있고, 후에 Access자체가 빨라질 가능성도 희박하다고 볼 수 있습니다.

그럼, RAW Device 혹은 O_DIRECT는 무엇인가? 주목해야 할 점은 두 가지..

- Memory의 절약
- Data의 정합성

Memory의 절약은 Buffer를 쓰지않으므로 Memory 절약이 가능한 만큼 Buffer pool에 비중을 높여 Cache hit rate를 올리는 것이 가능할 지도 모르겠지만, 최근엔 Memory를 많이 탑재하고 있어서 그다지 ..
Data의 정합성은 성능은 아닙니다. 복수의 서버에서 Disk를 동시에 사용할 경우(예. Oracle RAC) 필수. 현재로써는 Raw Device 혹은 O_DIRECT는 MySQL에서 사용해도 그다지 Merit가 없다라는게 의견.

추가로, Oracle에서도 Raw Device이용은 Option은 필요없습니다. Option이 필요한 건 O_DIRECT와 비동기 IO입니다. Oracle의 경우, 원래 물리배치를 고려 후 Access 이므로 그다지 변화가 없다라는 의견이 많습니다. 비동기 IO는 효과가 있다고 합니다만. InnoDB는 기본적으로 스스로 비동기 IO와 같은 움직임을 하고 있는 것 같아 보입니다.

추가)
Raw Device의 이용이 반드시 좋다고 할 수 없는 이유는 Kernel이 IO Scheduler를 사용해 효율 좋게 정리해서 Write를 해 준다는 것 입니다. (App=MySQL과 Kernel에서 2중으로 Buffering을 하여 Overhead하는 것 보다, 정리해서 IO를 사용하는 것이 효율성이 좋다)
Kernel Cache를 사용하면서, ACID 보증을 위한 Data Write를 어떻게 할 것인가..
Battery backup이 있는 Write Cache 대응의 RAID Controller를 사용하면서, O_DIRECT를 지정한다 등.. 성능도 ACID도 OK 현실적으로는 그 이상 필요가 없을지도..