[질문] 파일의 앞쪽을 잘라버릴수 있는 파일시스템이 있나요?
글쓴이: doraq / 작성시간: 수, 2007/08/08 - 11:55오전
말 그대로 파일의 앞쪽을 잘라서 버릴수있는...
즉, 중간 이후부터의 부분을 취하는 그런 기능이 있는
파일시스템이 있나요?
기존꺼에서 조금만 바꾸면 될만도 한데...
있을만도 한데 못찾겠네요.
멀티미디어파일의 경우에는 보통 파일이 크게 마련이니까 있으면 좋거든요.
그런 FS 수배합니다.
Forums:
있는지는 모르겠고...
있는지는 모르겠고... 그게 왜 필요한지 잘 모르겠습니다. 아.. 특별히 무슨 의미가 잇는건 아니고 정말 궁금합니다. 멀티미디어 파일의 경우 필요할 때가 있을 거 라고 말씀 하신 듯 한데... 왜 필요한가요? 저는 정말 잘 모르겠습니다.(창의성이 없는 건지. 제가...)
----
Lee Yeosong(이여송 사도요한)
E-Mail: yeosong@gmail.com
Blog: http://blog.lecl.net:8888/lanet/
Wiki(Read-Only): http://yeosong.lecl.net:8888/wiki/
MSN: ysnglee2000@hotmail.com
----
웃음... 행복... 평화... (진정한...) 희망... 사랑... 이 세상 모든것이 그렇다면 얼마나 좋을까...(꿈 속의
사람천사
이럴때 필요합니다.
제가 linux로 HD PVR 셋탑을 만들거든요.
큰 파일의 앞 1/3쯤을 편집해서 없애고 싶을때나....
타임머신TV라고 있죠? TimeShift기능이요.
이 기능의 구현중에..
TimeShift를 위해서는 내부적으로 파일을 녹화합니다.
생방송도 그 녹화된 부분만큼 뒤로 돌려서 볼수있는거죠
그런데 지금(Live시점)이 아닌 이미 녹화한 어느부분 쯤부터 녹화를 하고 싶은 겁니다.
예를 들면 파일상으로는 1G어치중에 뒤쪽 500MB만 필요하게 된거죠.
작은 파일이라면 그냥 앞의 불필요한부분까지 다 녹화해버리고 플레이만
시작시점부터 할 수도있겠지만, 이런 멀티미디어 파일들은 그러기엔 너무 낭비가
크니까요.
inode도 좀 복잡한 다단계식의 linked list로 본다면 앞 뿐만아니라 중간이나 아무 곳이라도
편집해서 해제가 가능할 텐데요.
파일 시스템의
파일 시스템의 문제가 아니라 시스템콜의 문제가 되겠습니다.
timeshift 용 데이타에 대해 통상적인 파일시스템이 필요한지 부터 진지하게 생각해보세요.
OTL
외부로 파일을
외부로 파일을 카피하는 기능이 있는지 없는지에 따라 다르겠지만, 아마도 DVR이라면 이런 기능이 없을 가능성이 높으니 스토리지에 파일시스템을 올리건 말건 만드는 사람 마음이겠지요.
하드디스크로 circular queue 하나 만들어 쓰시지요. :-)
그래도 여러파일을 운용해야 하는데..
녹화를 여러개 하게 될거고. 지우고 쓰고 하다보면 단편화도 일어날거고.
이런거를 일일이 구현하느니 그냥 파일시스템을 쓰는거죠.
즉 기본적인 파일시스템의 기능모두+기타등등 이 되는거니까요.
그리고 외부(PC)로 파일 꺼내는거 있습니다.
파일을 100M 단위로
파일을 100M 단위로 저장하면..?
----------------------------------------------------------------------------
C Library Development Project
----------------------------------------------------------------------------
일정 단위로 저장이라..
파일시스템의 기능으로서가 아니라 APP에서 일정크기로 저장한다면야..
기능구현의 레벨이 달라질뿐 되기야 되겠져...
그런데 I frame 하나가 파일 두개에 걸치거나 하는 식의 상황이
상당히 불편하게 될듯하네요.
파일시스템도
파일시스템도 아이노드를 조작하면 원하는데로 될텐데요..
----------------------------------------------------------------------------
C Library Development Project
----------------------------------------------------------------------------
네, 바로 그런걸 찾는거예요.
그런 기능이 있는 파일시스템이 기존에 있을것도 같아서요.
만들때 만들더라도 일단 공개수배는 한번쯤 해 봐야죠.
파일시스템을 쓸 필요가 있을까요
어쩌면 저랑 면식이 있으신 분이신지도 모르겠네요.
아예 파일시스템을 안쓰는게 어떨까 하는 생각이 드는군요.
특히나 새로 만들 생각까지 하신다면...
Linux나 Embedded System의 파일시스템에 대해서 아는건 별로 없지만
DB 구축할때는 항상 성능문제 때문에 파일시스템을 올리지 않고 raw device에 데이터파일을 만들었었거든요.
저널링 파일시스템을 쓰고 계시다면 성능 차이가 더 많이 나는걸로 알고 있습니다.
제가 아는 분이라면 아마 사업부 내에서 실제 그렇게 적용된 사례를 찾으실 수 있을겁니다.
적용 대상이 PVR 머신이라..
TV프로그램을 녹화하고 지우고를 자주합니다. 단편화를 해결해야죠.
파일시스템을 안쓴다해도 기본적 기능은 구현해야하니까
결국 엉성한 파일시스템의 모양새가 다시 나타날거같거든요.
그리고 성능도 빠르면야 좋은데 Ext3가 간신히 제한시간안에서 동작은 해주더라구요.
가전제품이 켜지면서 몇십분씩 복구를 할순없으니 저널링을 할수밖에 없는거구요.
기존의 파일시스템에서 inode조작으로 기능을 추가하는게 나을거같네요.
PS: 아시는분은 아닌거같습니다.
인용:그런데 I frame
안녕하세요... ;)
저도 100메가쯤의 단위로 나누어 저장하는 방법으로 PVR을 구현했었습니다.
어플에서 I, B 모두 검사해서 기록하는 기능이 있었는데, frame이 걸치는 문제는 어플리케이션에서 두 파일을 연속적으로 접근하게끔 구현을 해 비교적 간단하게 구현을 했구요...
그리고 리눅스를 쓴다면 network이 붙거나 PC인터페이스가 있을꺼구... 그럼 fs를 쓰지 않을 수 없죠... 더군다나 임베디드라면 저널링도 필요할 꺼구... 기능에 따라 다르겠지만, 이것저것 본다면... fs 없이는... 영... 구리한 제품이죠...
댓글 달기