구차니의 잡동사니 모음

AMD에서 CMT를 밀었다 말아 먹고 SMT 구조로 온건가..

Cluster based Multi threading - CMT

[링크 : https://scalibq.wordpress.com/2012/02/14/the-myth-of-cmt-cluster-based-multithreading/]

Simultaneous multithreading - SMT/HT(Hyper Threading) 하드웨어 레벨의 멀티쓰레딩(슈퍼스칼라 cpu가 필수조건)

Chip-level multiprocessing - CMP 혹은.. SMP 일려나(Symmetric Multi Processing?)

[링크 : https://en.wikipedia.org/wiki/Simultaneous_multithreading]

[링크 : https://ko.wikipedia.org/wiki/동시_멀티스레딩]

---

가장 위의 링크를 요약하면..

AMD는 CMT 구조로 가기 위해서 트랜지스터 조낸 때려박았으나 CMT를 비활성화 하면

비활성화된 코어 갯수 만큼 ALU도 같이 비활성화 되지만

Intel의 SMT 구조는 SMT를 비활성화 하면 한쪽 코어에 ALU를 몰빵해주어서 더 성능이 오르는 구조

머.. 이런 의미인듯.

SMT는 불도저 에서 부터 마켓팅 용어로 꺼낸걸려나?

[링크 : https://en.wikipedia.org/wiki/Bulldozer_(microarchitecture)]

샤딩이라길래 쉬이딩 오타인줄 알고 찾아봄

일단 원리는...

테이블별로 서버를 분할해서 접속하는 식으로 로드 밸런싱을 하거나

동일 테이블에서 레코드를 구분해서 밸런싱 하는 등의 방법..

[링크 : http://mongodb.citsoft.net/?page_id=225]

• Coded slice (regular VCL data),

• Coded data partition A, B, C (DPA, DPB, DPC),

• Instantaneous decoder refresh (IDR),

• Supplemental enhancement information (SEI),

• Sequence and picture parameter set (SPS, PPS),

• Picture delimiter (PD) and filler data (FD).

[링크 : http://iphome.hhi.de/wiegand/assets/pdfs/DIC_H264_07.pdf]

[링크 : http://stackoverflow.com/questions/12320604/embedding-metadata-to-h-264-encoded-file]

[링크 : http://egloos.zum.com/yajino/v/782492]

[링크 : http://mmlab.knu.ac.kr/Lecture/hci/multi_2008_2/H.264_AVC_2008_7.pdf]

SODB (String Of Data Bits)

RBSP (Raw Byte Sequence Payload)

NAL(Netwrok Abstract Layer)

[링크 : https://codesequoia.wordpress.com/2009/10/18/h-264-stream-structure/]

[링크 : http://vaplab.ee.ncu.edu.tw/~mktsai/data/h264_introduction.ppt]

format pdf

[링크 : http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.264-200305-S!!PDF-E&type=items]

[링크 : http://mmlab.knu.ac.kr/Lecture/hci/multi_2008_2/H.264_AVC_2008_4.pdf]

[링크 : http://iphome.hhi.de/wiegand/assets/pdfs/DIC_H264_07.pdf]

raid5가 의외로 고자라니... ㄷㄷㄷ

raid5는 N-1의 공간 효율을 가지는데

CRC 하나라서 동시 디스크 2개 이상의 손상에 대해서는 복구할 방법이 없다.

그런데 정작 필드에서 복구율을 보면 raid 라고 하기 처참한 상황

아래 그래프가 맞자면 raid0이랑 별반 다름없는 상황인데

하드가 3년 정도 주기로 서버에서는 교체할테니 고장률 35%대..

[링크 : http://linux.krauss.kr/doku.php/raid_신뢰성_고찰]

아무튼 이런 이유로 대세는 raid6 라고..

음.. 대충 이해한걸로는

하드 데이터 복구랑 비슷한 기분?

파일이 삭제 되거나 수정하면

다른 inode에 저장/삭제를 할 텐데

file system 레벨에서

그걸 삭제한게 아니라 version history 관리하듯

촤르륵 목록으로 냅두고 실제로 삭제하지 않음으로서

inode 목록만 저장(snapshot) 해두고

그걸로 이전의 시간대로 복구하는 개념..

CoW(Copy on Write) 는 스냅샷을 구현하는 방법론이 되려나?

[링크 : http://hybridstoragekorea.blogspot.com/2013/10/blog-post_4204.html]

[링크 : http://searchdatabackup.techtarget.com/...snapshot-technologies-for-data-protection]

고민을 해보니.. SSD에서는 구현 못하는거 아냐? inode가 붕뜨면 삭제처리 할텐데?(Trim)

했는데.. fs 레벨에서 inode 삭제가 아니라 삭제된 inode로 다른 테이블에서 실 데이터로 관리해주면

trim에 의해서 삭제 되지 않을테니 문제 없음! 이 될 것 같고

하드 공간이 넉넉하지 않으면 엄청난 성능 저하 및

snapshot으로 복구 할 가능성이나 시간대역이 짧아질 문제가 있을 것으로 보인다.

만약.. 4T 하드에 3T 내용이 있고

그 내용 전부를 크립토락커로 당했다면.. 전부 복구가 불가능 해질 가능성도 존재할 것으로 생각이 된다...

(아니면 말고..)

한마디로.. 삭제 된 파일도 실제 FS 상에서는 .remove 식으로 관리해둔다고 보면 될 듯?(리눅스 기준)

+

저널링은 갑작스런 전원 중단으로 인한 불일치를 복구하는데 유리한 시스템이고

(commit이 완료되면 엎어씀)

스냅샷은 엎어쓰지 않아서 정전과 상관없는 백업을 유리하게 하는 시스템..

Versioning file systems should not be confused with journaling file systems. Whereas journaling file systems work by keeping a log of the changes made to a file before committing those changes to that file system (and overwriting the prior version), a versioning file system keeps previous copies of a file when saving new changes. The two features serve different purposes and are not mutually exclusive.

[링크 : https://en.wikipedia.org/wiki/Versioning_file_system]

예전 멀티프로세서 환경에서의 세마포어 등을 공부할때(OS 수업)

들은거 같은데 기억이 안나서 뒤적이다가 겨우 찾았네..

왜 쓸데없는(?!) TLB랑 용어를 헷갈린거지?

[링크 : https://en.wikipedia.org/wiki/Test-and-set]

정확도 면에서는 NTP 만큼의 정확도를 요구하지 않는 표준안

PTP > NTP > SNTP 순일려나?

[링크 : https://www.meinbergglobal.com/english/faq/faq_37.htm]

[링크 : https://www.meinbergglobal.com/english/glossary/sntp.htm]

[링크 : http://www.rfc-base.org/txt/rfc-2030.txt]

[링크 : https://en.wikipedia.org/wiki/Network_Time_Protocol#SNTP]

MMIO 반대말이 안떠올라서 저장 ㅋ

Memory-mapped I/O (not to be confused with memory-mapped file I/O) uses the same address bus to address both memory and I/O devices – the memory and registers of the I/O devices are mapped to (associated with) address values. So when an address is accessed by the CPU, it may refer to a portion of physical RAM, but it can also refer to memory of the I/O device. Thus, the CPU instructions used to access the memory can also be used for accessing devices. Each I/O device monitors the CPU's address bus and responds to any CPU access of an address assigned to that device, connecting the data bus to the desired device's hardware register. To accommodate the I/O devices, areas of the addresses used by the CPU must be reserved for I/O and must not be available for normal physical memory. The reservation might be temporary, such as with the Commodore 64 that does bank switching between its I/O devices and regular memory, or permanent.

Port-mapped I/O often uses a special class of CPU instructions designed specifically for performing I/O, such as the in and out instructions found on microprocessors based on the x86 and x86-64 architectures. Different forms of these two instructions can copy one, two or four bytes (outb, outw and outl, respectively) between the EAX register or one of that register's subdivisions on the CPU and a specified I/O port which is assigned to an I/O device. I/O devices have a separate address space from general memory, either accomplished by an extra "I/O" pin on the CPU's physical interface, or an entire bus dedicated to I/O. Because the address space for I/O is isolated from that for main memory, this is sometimes referred to as isolated I/O.

[링크 : https://en.wikipedia.org/wiki/Memory-mapped_I/O]

쓸일이 있을진 모르겠다 -_-a

[링크 : https://users.cs.jmu.edu/buchhofp/forensics/formats/pkzip.html]