Messages in this thread | | | Date | Sun, 19 Sep 2004 22:49:06 +0300 | From | Tuomas Heino <> | Subject | vfs hacking q: implementing "sectorfs" - hints? |
| |
Being faced with the problem of data recovery from broken hard drives once again one of the ancient *ix:ish ideas crossed my mind.
Everything(*) is a file.
Thinking more of it, why couldn't harddisk sectors be files themselves? That'd give me the power to use several userspace tools on those sectors without writing any unnecessarily complex glue software to accomplish the same goal. So I could do something like this to analyze the contents of the drive (mounting tmp file instead of real h/w because actually mounting something on a piece of broken h/w sounds too damn risky):
# dd if=/dev/sda of=try001.sda bs=512 conv=noerror 2>try001.err # mount -t sectorfs -o loop try001.sda /mnt/mnt1 # find /mnt/mnt1 -type f -print0 | xargs -0 file > try001.contents
And thus get an approximate list of what is contained in each sector; each virtual file would contain just the contents of one sector. So, on to my actual questions: Assuming this idea hasn't been shot down before, where should I start? Would such a relatively simple "fs" fit in the kernel land better than in the userland?
As most hard drives nowadays have several millions of sectors, such a fs would need some levels of hierarchy for efficiency reasons. A natural idea would be using real harddisk geometry as a basis for the directories but recent drives tend to abstract the real geometry away from the casual observer :-(
Any ideas on what could actually be a useful directory structure? If I'd actually start to write such a thing in the kernelspace, should I be aware of some common pitfalls? Or does this already exist in some other form that managed to escape my & google's imagination?
-- Tuomas Heino <iheino+lkml@cc.hut.fi> *: Every rule has an exception. Except... you know :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |