A development plan & process.

[kyungmin-Earnest-Lim]

We will give a special zone for journal data. In conventional zone, zone is mixed with file data and journal data.

One of the Journal data`s feature, journal data is rewritten when zone is filled.

But ignored this feature, when zone is reclaimed, if journal data is mixed with file data, valid journal data is copied to new place, it called by Write Amplification.

So, In future, We will find how many journal data is copied when reclaim is happened for measuring about Overhead.

[kyungmin-Earnest-Lim]

ext4 file system에서 journaling 개념 중 journal data는 zone에 commit되고 나면 다시 쓰일 때 원형 형식으로 끝까지 다 쓰고나면 다시 돌아와서 덮어쓰기를 한다.

근데 ZNS 상에서 zone이 reclaim될 때, 해당 zone에 file data와 journal data가 같이 있다면 journal data는 copy될 필요가 없는데 valid data의 copy가 일어나므로 이것 자체가 Amplification의 발생, 즉, Overhead이다.

그래서 우리는 Zone에서 journal 데이터가 reclaim시 얼마나 copy가 일어나는지를 분석하고, journal용 zone을 따로 빼두어 해당 zone에서만 journal을 다룰 예정이다.

[kyungmin-Earnest-Lim]

Q1. Journal은 commit되고나면 그 다음부터는 필요가 없다????

Q2. ext4 file system을 거쳐서 journal이 내려오는데 LBA는 PBA의 형상화이니까 LBA도 ZNS 상에서는 Zone으로 생각해야 하는지??

[kyungmin-Earnest-Lim]

journal data가 reclaim시에 copy가 일어나는지 분석 zone copy가 일어날때 dmz_first_valid_block -> 첫번째 valid block을 zone의 chunk block에서 찾는다. 찾으면 그 number가 return 그리고 chunk_block의 전체 valid block의 수가 return 된다. -> dmz_first_valid_block을 통해서 journal block을 찾으려 했으나 chunk_block의 용도는 개수만 세어준다. 여기서는 valid journal block을 찾기 힘들다 판단

둘째로 dm_kcopyd_copy를 통해서 copy가 일어날시에 valid journal data의 이동을 확인해주려 했으나 807번줄에서 if 조건문에서 host managed zbd이면 set_bio 이부분이 write sequentially라고 생각했지만 들어가보니 알수없는 assembly code 직면

세번째 저널 블록이 저장되어있는 갯수가 들어있는 배열 -> index는 zone의 개수 파일 블록이 저장되어있는 갯수가 들어있는 배열 -> index는 zone의 개수

예를들어 저널 블록이 17번 zone에 들어간다고 하면 17번 index에 수가 1올라갈것. 똑같이 다음 저널 블록이 또 17번 zone에 들어간다고 하면 저널 배열의 17번 index의 값이 2로 올라가게 배열을 구성하고

reclaim될 때 어떻게 할지 -> reclaim이 발생하면 3가지 경우가 있다. rnd_data -> seq data zone -> 만약 6번 zone에서 17번 zone으로 옮겨졌다고 하면 reclaim 대상이 된 저널 데이터 수 = 저널 배열[6]

reclaim buf 경우에 버퍼에 있는 valid block을 dzone으로 옮기는 것 마찬가지로 6번 zone의 block들이 17번 zone으로 옮겨졌다고하면 저널 배열[6] ++

이 수치만큼의 write amplification이 일어났다 reclaim 대상이 된 저널 데이터의 수

네번째, block size = 4k, zone size = 128MB이다. -> 그럼 zone안에 block이 32000개가 있다는 말이 된다. 👍 bio가 내려올때 우리는 bio_flagged를 통해서 해당 bio가 journal인지 file data인지 구별을 해줄 수 있었다. -> bio가 내려오는 동작은 reclaim동작과 별개의 동작이므로 bio가 내려왔을 때 zone에 저장되는 journal 혹은 file data의 정보를 reclaim에 쓸 수 있게 저장해둘만한 배열이 필요하다. -> 이 배열을 dm_zone에 저장해두고 reclaim에서 쓰자.

-> reclaim에서 함수 파라미터로 bio를 받아올까했는데 복잡하고 처리도 어렵다. 그리고 우선적으로 그것이 가능할 지도 모름

구현은 우선 예를 들면 if(block == journal) 이면 -> journal_copy_count++; 이런식으로 ==> if(zone_journal_block[1] == 1) -> cnt++; if(zone_journal_block[2] == 0) -> x 이런 식으로 구현

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ 방법 5 👍 👍 👍 1. 옵션 -> EXT4 filesystem 에서 보면 journaling 옵션이 ordered mode. mount 할때 옵션을 줄 수 있는데 mount 모드를 journal로 바꿔서 하면 모든 파일에 대해 journaling을 수행하므로 오버헤드가 더 많이 발생하지만 저널링 데이터가 확인이 더 잘된다. 위의 그림에서 보자면 JBD에서 journal이 chunk 17번을 통해서 내려오고 LBA(logical block address) 이것과 zone reclaim이 일어날때 valid block이 copy가 일어난다 가정하고 해당 block이 zone_id와 block offset을 가진다. 여기서 chunk는 해당 zone과 매핑되어있는 data chunk LBA -> PBA로 가는데 여기서 jbd에서 journal이 chunk 17번에 내려온다고 하자 그럼 이 chunk 17번은 어떤 zone에 mapping되어있겠지 reclaim됐을 시 zone에 있는 chunk id하고 비교해서 chunk number는 안바뀌니까 해당 chunk number를 비교해서 맞으면 journal copy가 일어났다. 그리고 copy가 일어난 block offset도 구해줘야한다.  (1 block은 8개의 sector가 모여서 이루어진다.) 먼저, chunk란 ZNS SSD안의 Zone과 같이 LBA 영역에서의 zone size와 같이 나눈것을 chunk 둘째, LBA(logical block address)는 chunk와 offset을 연결시키면 얻을 수 있는데 그 값은 sector로 표현된다. 셋째, struct dm_zone인 src_zone에서 reclaim_copy가 일어날 때 LBA 출력 dst_zone에서 offset과 chunk번호를 묶으면 LBA 계산 가능 고로 LBA는 chunk - sector를 묶은 것 sector가 8개가 모이면 block이 되므로 block 개수로 내려오니 sector number에서 이진수 맨 뒤 3자리를 때고 (sector 묶음이라서) sector number 만큼 >> (shift) 해주면 3978b0 3978b8 3978c0 001110 010111100010110 000 001110 010111100010111 000 001110 010111100011000 000 12fae8 000100101111101011101000 000010010111110101110100 000001001011111010111010 000000100101111101011101 000000000000000000000100 결국 chunk number 확인 가능 LBA : 0111000101110 chunk : 01110 block offset : 00101110 Chunk당 Block 개수 : 2^8개 2^8 -> 100000000 - 1 011111111 256 128 64 32 16 8 4 2 1 dmz_zone_nr_blocks(zmd) - 1 256 - 1 = 255 = 011111111 / 387 /+ 255 /-------------- / *** / / 0111000101110 /& 0000011111111 /--------------------------- / 0000000101110

[kyungmin-Earnest-Lim]

방법 5번 reclaim시 copied data 의 LBA 출력하기

take 1.

• dm_zone struct에 chunk variable에 chunk number가 기록되어 있으니까 offset만 구해준다면 매칭하여 LBA를 구할 수 있다.
  • 그러기 위해서는 dmz_first_valid_block의 parameter중 chunk_block &block 이 있다. 이것은 함수 내부에서 첫번째 valid block의 offset을 담고 있다.
  • 기존 code에 영향이 가지 않기 위해 별도의 변수를 뽑는다.
  • sector_ret 변수에는 rotate부터 다음 valid block까지 얼마만큼 떨어져있는지 저장
  • rotate 변수 값에 sector_ret을 더해주면 zone에서의 offset값을 구할 수 있다.