(심층분석) 책을 보면, page cache 내부에서 특정 page들을 찾기위해서. 블록의 noncontiguous한 속성때문에..
device name과 block number 만으로는...찾을수 없다 라고 씌어있네요. 따라서. address_space object라는걸 사용한다고 하네요.
device name과 block number 만으로는 어떤점때문에 부족한지 궁금합니다 :))
질문에 쓰여져 있는데요.. noncontiguous 속성때문에요...
device name - 무슨 device 인지 block number - device 내에서 몇번째 block인지
를 이용하면 원래 해당하는 block을 찾을 수 있는데 noncontiguous(불연속)적인 속성 때문에(뭐 중간에 hole에 있다거나 뭐 이런...) 찾을 수 없다는 거죠..
page cache에 있는 page는 logical한 일반적으로 4K단위입니다. 이 4K page를 구성하는 block들의 physical한 위치는 fs마다 틀리며 스토리지의 물리적으로 연속되지 않은 곳에 존재할 수 있습니다. 그러므로 kernel은 logical한 page의 4K를 physical한 block들과 연관을 맺게 해야 합니다. address_space의 operation들이 그런 가교 역할을 하게 됩니다.
address space 가 바로 OS 시간에 배웠던 그 Address space 입니다.
User sapce 3GB, Kernel Space 1GB 이고
특정 데이터가 필요해서 파일 시스템을 통해 Read 를 하면
데이터는 버퍼캐쉬와 페이지 케쉬를 통해서 특정 Process의 특정 Address에 연결되게 되는거죠.
Dig it.
텍스트 포맷에 대한 자세한 정보
<code>
<blockcode>
<apache>
<applescript>
<autoconf>
<awk>
<bash>
<c>
<cpp>
<css>
<diff>
<drupal5>
<drupal6>
<gdb>
<html>
<html5>
<java>
<javascript>
<ldif>
<lua>
<make>
<mysql>
<perl>
<perl6>
<php>
<pgsql>
<proftpd>
<python>
<reg>
<spec>
<ruby>
<foo>
[foo]
음..
질문에 쓰여져 있는데요.. noncontiguous 속성때문에요...
device name - 무슨 device 인지
block number - device 내에서 몇번째 block인지
를 이용하면 원래 해당하는 block을 찾을 수 있는데
noncontiguous(불연속)적인 속성 때문에(뭐 중간에 hole에 있다거나 뭐 이런...) 찾을 수 없다는 거죠..
책을 보지 않아 어떤 의미로 저자가 기술했는지는 모르겠지만,
page cache에 있는 page는 logical한 일반적으로 4K단위입니다. 이 4K page를 구성하는 block들의 physical한 위치는 fs마다 틀리며 스토리지의 물리적으로 연속되지 않은 곳에 존재할 수 있습니다. 그러므로 kernel은 logical한 page의 4K를 physical한 block들과 연관을 맺게 해야 합니다. address_space의 operation들이 그런 가교 역할을 하게 됩니다.
address space 가 바로 OS
address space 가 바로 OS 시간에 배웠던 그 Address space 입니다.
User sapce 3GB, Kernel Space 1GB 이고
특정 데이터가 필요해서 파일 시스템을 통해 Read 를 하면
데이터는 버퍼캐쉬와 페이지 케쉬를 통해서 특정 Process의 특정 Address에 연결되게 되는거죠.
Dig it.
댓글 달기