How Windows 7 will, and won't, work better with SSDs

녹차의 이미지

http://www.cio.com.au/article/266551/how_windows_7_will_won_t_work_better_ssds?pp=1

크게 3가지가 있네요. NTFS를 직접 수정할 계획인가 봅니다.

1. Windows 7 will turn off disk defragmentation when it detects an SSD instead of a spinning disk drive.

SSD를 디스크 처럼 데이터를 Sequential하게 배치할 필요가 없으므로, 당연히 조각모음은 비활성화해야겟죠.

2. Windows 7's new "trim" feature will improve performance three ways.

Trim이라는 명령어를 통해서 데이터 삭제 처리를 한다고 합니다. 일반적인 파일시스템은 파일이 지워질 때, 메타데이터만 삭제하고 데이터 영역은 그대로
두는데, 이는 SSD에서는 메타데이터 영역의 변경만으로는 파일 삭제 여부를 알지 못하므로, 그대로 살아 있다고 판단, 그대로 둠으로써, 가비지 컬렉션 시에
많은 부담이 가해져, Write의 퍼포먼서를 낮추었다고 하네요. 파일 삭제 여부를 직접 알려줘서 해결한다고 합니다.

3. Third, Windows 7 will partition the SSD more efficiently to cut down on unnecessary read-write cycles

파일 시스템의 시작이 SSD 내의 페이지 단위라 맞지 않아서 생기는 문제인데요. 파일 시스템의 시작 위치가 페이지 중간에 위치함으로 인해서
Write 한번 할 것으로 2번해야하는 문제가 발생하고, 이미 데이터가 기록되어 있다면 이 또한 데이터를 다시 읽어서 변경한 뒤에 다시 써야 한다는 문제 때문에 성능이 많이 저하
되었다고 하네요. 이것을 해결한다고 합니다.

결국 현재 SSD 환경을 좀 더 잘 지원하겠다는 건데, SSD 성능이 많이 좋아질 거 같네요. 특히 한달만 쓰고나면 Write 성능이 엄청 떨어졌었는데 그것이 해결될 것으로 판단됩니다.

리눅스에서도 이런 작업을 해줘야 할 거 같은데요.

bushi의 이미지

파일시스템이 한개(두갠가..) 뿐이니 구워먹든 삶아먹든 마음대로 해도 무슨 문제겠습니까.

리눅스에도 이미 준비는 되어 있습니다.
block device subsystem 에 read/write 외에 discard 가 들어간지 오래지만,
각 파일시스템 및 장치 드라이버들이 이걸 쓰도록 수정을 해야 동작하던가 말던가하죠.

OTL

cppig1995의 이미지

플래시 파일 시스템이라면... FAT32(저용량은 16), NTFS 외에 JFFS2인가요?

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

bushi의 이미지

SSD 는 ATA 혹은 SATA 처럼 보입니다.
그래서 문제가 되는거죠.
전통적인 파일 시스템을 그냥 사용할 수 있긴 한데,
전통적인 파일시스템이란 것들이 read/write 만 생각하고 있지 그 밖의 것은 생각하지 않고 있으니까요.

OTL

bushi의 이미지

소식이 들려도 그냥 그런가부다하고 넘기고 있다가... 어떤 계기로 찾아봤는데...
btrfs 에서 discard 요청을 사용하는군요.
http://lxr.linux.no/#linux+v2.6.31/fs/btrfs/extent-tree.c#L1510

그런데... discard 요청을 제대로 처리해주는 block 장치드라이버는 못 찾겠습니다.
TRIM 커맨드를 사용하게 하는 libata 패치가 메일링리스트에 올라온 게 전부군요.
http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-04/msg01269.html

+

btrfs.. 여러가지로 신묘하군요.
파일시스템 수준에서 non-rotation 장치인지 아닌지 여부에 따라 다르게 동작하네요.
http://lxr.linux.no/#linux+v2.6.31/fs/btrfs/volumes.c#L1521
SSD 뿐만 아니라 SD 메모리카드등에서도 유용할 것 같은데... 이쪽은 뭐 눈물을 머금고 vfat 을 써야하니 안습.

OTL

hb_kim의 이미지

이전의 고성능 파일시스템을 보면, write 를 아무곳에나 할수 있는 디자인에 큰 이점이 있었읍니다.

보통 HA 스토리지의 경우 하단은 데이터 안정성을 위해서 레이드 5 등으로 묶는 경우가 많은데, 이 경우 데이터 블록이 상당히 커집니다. 따라서 이 데이터 블록보다 크기가 작은 쓰기를 많이 하게 되는 파일 시스템의 경우, 하단의 레이드에서 많은 Read-Modify-Write 를 가져오게 되서 성능의 저하를 가져오기 때문입니다. 따라서 레이드5위에서 파일 시스템이효율적으로 작동하기 위해서는 메타 데이터와 유저 데이터가 순차적으로 쓰여질 수 있는 파일 레이아웃을 지원하지 않으면 안됩니다. (이를테면 NetApp 의 WAFL 같은)

그런데 SSD 에 사용되는 플래시 메모리의 경우 마치 레이드 5와 비슷한 특성을 가지고 있습니다. 플래시 디바이스가 읽는 것은 4K-8K 정도의 페이지단위로 읽지만 쓸때는 이 페이지가 수백개가 모여있는 블록 단위로 써야 합니다. 따라서 작은 조각 데이터를 읽는것은 문제가 되지 않는데, 작은 조각 데이터를 쓰는것은 매우 비효율적인 Read-Modify-Write 를 발생시키기 때문입니다.

효율적으로 SSD 를 설계하려면 당연히 이전의 고성능 파일시스템에 사용되었던 디자인을 응용하지 않을수 없습니다. 하지만 단순히 기존의 파일 시스템 디자인을 무작정 모방해서 사용할 수 없는게 상단의 인터페이스가 파일 인터페이스가 아니고, 블록디바이스 인터페이스라는 점입니다. 따라서 이전의 파일 시스템 디자인에서 부각되지 않던 logical ->physical 매핑이나 space utilization 문제가 크게 드러나게 됩니다.

디프라그멘테이션 을 끄거나 TRIM 등의명령을 도입하는것은 겨우 시작단계에 불과하고, 엔터프라이즈 영역에서는 앞으로 파일시스템과 볼륨매니저 등 소프트웨어를 포함해서 서버의 모든 구성요소의 기본 디자인이 바뀌지 않을까 생각됩니다.

녹차의 이미지

플래시 디바이스가 읽는 것은 4K-8K 정도의 페이지단위로 읽지만 쓸때는 이 페이지가 수백개가 모여있는 블록 단위로 써야 합니다.

플래시 메모리는 read write의 단위는 page이고 erase는 블록 단위로 알고 있는데 이 부분은 잘못된 정보로 보입니다.

read-modify-write 문제도 크지만 아무래도 small file이 random한 양상을 보여주기 때문에 성능이 낮지 않을까요?

SSD 업계나 학계에서 random write의 성능을 높이는 것이 주요 이슈가 되지 않을까 보는 것도 그 이유 중의 하나구요.

hb_kim의 이미지

write 는 페이지 단위로 한다고 하지만 어짜피 write 하기 전에는 꼭 블록 erase 를 해줘야 하기 때문에 write 를 블록단위로 하지 않을수가 없습니다. 개개의 페이지를 쓰기는 하지만, 다음에는 꼭 인접한 다음 페이지를 써야 되기 때문이지요.

녹차의 이미지

예 말씀 해주신 것은 맞는데, 그렇다고 write의 단위가 블록이라는 말은 전혀 다른 이야기 입니다.

sequential 순서로, 각 페이지를 써야 하지만, 다른 블록에 있는 페이지를 써도 됩니다. 그렇다면 write의 단위가 블록이 모여 있는 칩 단위 뱅크 단위인가요?

무슨 의미로 말씀 해주신 것은 알지만, 플래시 메모리의 제약 사항으로 인해서 write의 단위가 블록이라고 주장하는 것은 좀 지나친 것으로 보입니다.


bushi의 이미지

모 업체에서 개발한 ftl 은 erase block size 만큼 버퍼를 잡아서 버퍼링한다죠.
결국, ftl 을 통해 일어나는 실제 flash write 의 단위는 erase block size 가 되고요.

.. 뭐.. 막가파 식이니.. 그냥 '그럴 수도 있다' 정도지만,
h/w 로 ftl 을 구현한다면, 용량 좀 되는 cap 이나 충전지 사용해서
flush 가 끝날 때까지 전력만 공급해 줄 수 있다면 버퍼를 충분히 크게 잡을 수도 있지 않을까요 ?
I/O 과정에서 erase 횟수가 줄면 결국 write 속도가 빨라지는 셈이고, 부가적으로 life time 도 늘어나고.

OTL

녹차의 이미지

그런 식으로 구현한다면 flash 의 write 실제 operation은 블록 단위로 이루어지겠죠.

버퍼와 mapping information으로 인해서 메모리 사용량이 많이 늘어나는 구조를 가지게 되겠지만,

어느 정도 장점을 가질 수도 있겠네요.

플래시 메모리 스펙에서 제시하고 있는 바처럼 read, write의 단위는 page, erase의 단위는 block이라고

나와 있는데, 각기 다른 구현을 가지고 거기 면에서 바라보고 그 구현에서 그렇게 write를 하니깐

그 단위가 플래시 메모리의 write의 단위라고 말하는 것은 잘못된 것이 아닌가요?

버퍼를 칩 단위로 두고, write를 하게 되면 플래시 메모리의 write 단위가 칩 단위라고 말할 수 있는건가요?

bushi의 이미지

말씀드렸다시피, '그럴 수도 있다' 이상도 이하도 아닙니다.

이때까지 ftl 혹은 filesystem 에 대해 얘기하고 있었던 것 아닌가요 ?

flash 의 write size 는 이미 그 flash 의 data sheet 에 구체적으로 수치를 적혀있고,
그 어떤 논쟁거리나 토론거리도 없는데요.
누가 그것에 대해 뭘 주장하기라도 했습니까 ?

OTL

녹차의 이미지

아.. 제가 오해를 했네요 죄송합니다.

hb_kim의 이미지

어짜피 선형 매핑은 불가능하고, 또 블록내에서는 순차적으로 페이지를 써야 하는 경우니까, 굳이 다른 블록으로 가서 다른 페이지에 쓸 이유는 없지 않습니까? 다른 블록으로 가더라도 역시 순차적으로 페이지에 써야 하니까 관리 부담만 늘어나지 않습니까.

데이터를 쓰기 위해서는 (페이지 단위로 쓰건 어떻게 쓰건간에) 그전에 블록을 지워야하는데 블록을 지우기 전에 기존의 데이터를 가비지 콜렉션해야 되고, 이 기존 데이터를 새로 들어온 데이터와 모아서 씁니다. 한 블록을 지웠을 때 나오는 유효 데이터는 over-provision 이 클수록 적은 데이터가 나오는데 over-provision 은 실제 유저 사용 용량을 줄이는 역할을 하므로 아주 크게 잡을수가 없습니다. 따라서 데이터를 쓰기 위해서 블록 하나를 가비지 콜렉트하고, 지우고, 데이터를 옮기고, 새로운 매핑에 해당하는 메터데이터를 만들고, 메터데이터가 어느 정도이상 모이면 이를 합쳐서 새로운 블록에 채워서 쓰게 됩니다.

결국 통상적인 경우 한 블록의 30-50% 밖에 안되는 새 데이터를 쓰는데 한 블록 전체를 써야합니다. 이 비율이 write amplification 비율이지요. 전체적인 디자인이 최적화 되어 있을때 이렇고, 사실 현존하는 SSD 들은 최적화 되어있는 경우가 거의 없다고 보입니다.

위의 과정만 해도 충분히 복잡하기 이를데 없는데, 여러 블록을 열고 포인터를 관리하면서 왔다 갔다 하면서 쓴다고 생각하면 왜 그렇게 하는지부터 우선 생각해 봐야되겠지요.

녹차의 이미지

많은 논문들이 여러 블록들에 대해서 write를 할 수 있는 구조를 가지고 있습니다.

random이냐 sequential이냐를 구분하기도 하고

혹은 hot이냐를 구분하여 각기 다른 블록으로 write하는 구조도 있습니다.

실상 한 블록에 대해서 write를 전적으로 다 수행하는 구조도 있겠지요.

요점은 한 블록에 대해서 write를 전적으로 수행하지 않는 구조도 있으니

write 단위가 블록이라는 건 아니지 않냐는 겁니다.