marcopon / seqbox Goto Github PK

I saw your SeqBox on /. I think it's great! I am just starting to learn about how filesystems work, because I'm playing around in x86 assembly writing a bootloader (because that's everyone's idea of fun, right?). Right now I only know how to read sectors from a floppy disk into memory, and reading up on FAT12 and even more advanced systems seems overwhelming. (Pretty much anything in assembly seems like an enormous task to me.) But with this, I could easily format the floppy as [whatever] and then use a for loop in my MBR bootloader to:

• read each sector into RAM one by one at a fixed location P
• look for the 'SBx' signature
• then read the sequence number
• multiply the sequence number by 512 to compute an offset
• copy the sector currently located at P to some fixed location plus that offset

To start, I would probably not worry about the checksum or even the UID since I only have one file. By the time the for loop has read the entire floppy, the kernel would be in memory!

Then I'd potentially be able to "drag and drop" kernel.bin files onto the floppy drive like a "real" disk! (Currently, I use dd every time to write the MBR+kernel to the floppy, and Windows complains every time I insert it asking to format it.)

In other words... I could write an assembly program that can read SeqBox files from a disk without having to write a file system driver!

Neat idea, although if you want it to get used you need a native C library (reference implementation) under a liberal license.

When reading the project description the only though I had in my mind was about use SeqBox as a filesystem format focused on reliability and data recovery (I like this kind of things :-) ), later I see that you had it also as a posible use case so hope to see it soon! :-D

I wonder how much resilient SeqBox is to different "corruption vectors" e.g. in comparison with https://github.com/ttsiodras/rsbep-backup (which shall need just an approximate offset of the file and corrects up to 65280 consecutive bytes including all metadata)?

Some typical issues with FEC (forward error correction) schemes are outlined in https://www.thanassis.space/rsbep.html (especially metadata FEC is often flawed or the number of consecutive errorneous bits/bytes/chunks is very limited - typically to 1 or 2 or the ratio between errorneous parts and the whole data size is highly insufficient for long-term storage etc.).

jfyi: sha256 < sha512(-256) < blake2b for 64bit cpus.

It's marked as not working due to 488B sectors, but since both systems use the same concept, probably the metadata fields of OFS could be used by SeqBox format changing this last one to use the same positions (like a "extension" of the OFS format).

A FreeBSD port has been created for SeqBox. Its status can be found here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218962