クイズ: fsimage・edits・セーフモード

NameNode 가 이름공간의 변경을 fsimage 에 바로 반영하지 않고 edits 에 따로 적는 가장 큰 이유는 무엇인가?

• fsimage 는 암호화되어 있어 NameNode 가 직접 고칠 수 없기 때문
• 변경마다 전체 사진을 새로 쓰면 비싸서 일지 끝에 붙이기만 하기 때문
• edits 는 DataNode 가 읽어야 하는 파일이라 따로 두어야 하기 때문
• fsimage 는 Secondary NameNode 만 쓸 수 있도록 잠겨 있기 때문

막 기동한 NameNode 가 바로 쓰기를 받지 않고 안전 모드에 머무는 이유로 옳은 것은?

• fsimage 를 다 읽기 전까지는 파일 이름을 하나도 모르기 때문
• Secondary NameNode 의 허락을 받아야 쓰기를 열 수 있기 때문
• 블록 위치는 디스크에 없어 DataNode 의 블록 보고를 기다려야 하기 때문
• edits 파일을 모두 지우고 새로 만들 시간이 필요하기 때문

hdfs-default.xml 기본값에서 체크포인트가 일어나는 조건으로 옳은 것은?

• 3600초가 지나거나 트랜잭션이 100만 건 쌓이거나, 먼저 닿는 쪽
• 3600초가 지나고 동시에 트랜잭션이 100만 건 쌓였을 때만
• NameNode 를 재시작할 때만, 주기적인 체크포인트는 없음
• edits 파일 크기가 128MB 에 닿을 때마다 한 번씩

hdfs dfsadmin -saveNamespace 를 안전 모드가 아닌 상태에서 실행하면 어떻게 되는가?

• 경고만 찍고 새 fsimage 를 정상적으로 만든다
• NameNode 가 스스로 안전 모드에 들어갔다가 나온다
• edits 만 새로 시작하고 fsimage 는 만들지 않는다
• 안전 모드가 필요하다며 거절되고 아무것도 저장하지 않는다

fsimage 를 스크립트로 세고 거르기 좋게, 경로·복제 수·블록 수·파일 크기를 한 줄에 하나씩 늘어놓는 oiv 처리기는?

• -p Web 처리기, 읽기 전용 WebHDFS 를 띄운다
• -p Delimited 처리기, 구분자로 칸을 나눈다
• -p stats 처리기, 연산 코드별 개수를 센다
• -p XML 처리기, 모든 정보를 태그로 감싼다

설정 없이 띄운 NameNode 가 서버 재부팅 뒤 이름공간을 통째로 잃을 수 있는 이유는?

• fsimage 를 메모리에만 두고 디스크에는 전혀 쓰지 않기 때문
• Secondary NameNode 가 없으면 edits 가 기록되지 않기 때문
• name.dir 기본값이 hadoop.tmp.dir 아래, 곧 /tmp 에 있기 때문
• 재부팅하면 DataNode 가 모든 블록을 지우기 때문