looking for an embedded filesystem, extremely simple

[legacy]

removed

[AlfBaz]

This project can be compiled and executed on your host PC in order to test/improve it, but it is still very ugly and need more works, also the media_disk is not working about "mount"

If the original code was developed on a PC prior to Win7 and you are having difficulties on Win7 let me know, I'll dig up my fat system and see what changes I had to make to accommodate some new security features introduced in W7

edit:
this code obviously needs a rewritten with a real bitmap, it's just a proof of concept

Code: [Select]

void disk_bitmap_set_used_block(uint32_t i)
{
    printf("block%ld is used\n", i);
    disk_bitmap_block_is_empty[i] = False;
}

void disk_bitmap_set_free_block(uint32_t i)
{
    printf("block%ld is free\n", i);
    disk_bitmap_block_is_empty[i] = True;
}


That's odd, an array (of unit32's no less!) holding true/false values for block usage?? Isn't that what the actual File Allocation Table is for?

[AlfBaz]

Is it a custom file system, FAT16/32 or some Linux system?

[AlfBaz]

what does it matter ?

In your original post you mentioned you could develop it on a PC. That's how I developed mine using a spare drive to mess around on.

To insulate fat development from the OS I created a couple of simple hardware access functions who's code would change depending on whether it was running on windows or an embedded target.

Simply a read and write block function that would either accept or return 512 byte block from the disk.

When I upgraded to W7 I had to add some IO_CTRL chicanery to give those hardware access funcs "permission" to gain raw disk access

[BloodyCactus]

why not use an already existing, tested working FS designed for embedding, yaffs, jffs2, logfs, ubifs,  etc?

[Bored@Work]

Sorry, it is really not clear what you want.

You have written your own file system and now want us to clean up the code?

You found some file system code somewhere and now want us to clean up the code?

You want to write your own file system, and want some clean code for it from us?

You want us to write you a file system?


And what is the embedded part supposed to be?

Will the file system be on an r/w media like an SD card?

Will the file system be on a (mostly) read-only media, more like structured, grouped data?

And if you look for a simple way to do a simple file system, the last time I needed to do my own I used a B*-tree. I have also used in the past what essentially amounted to a linked list and a simple block manager (cf. FORTH dictionaries, I probably took the idea from there). I have also done a read-only file system which was nothing more than a sorted index of names (to be binary searched), pointing to blocks. The data for such a file system was actually generated with a tool on a PC, converted into an Intel HEX file and burned into Flash.

[BloodyCactus]

what you really want then is basically, FAT16/FAT32. it doesnt get much more simple, and embeddable.

if you want to step up, something a bit more complex like an inode based filesystem like Minix/Ext2...

[BloodyCactus]

But if you look such a sources … they are ugly

who cares? does it work yes or no?

have you see the project i have put on google code ? It's browsable form the web.

It looks simpler than FAT32 and .. it is shorter than FAT32.
I can't say it is written better.

except it doesnt work and has not been tested.

if you want to step up, something a bit more complex like an inode based filesystem like Minix/Ext2...

too complex, too many C lines.

ugh. do you even understand the tradeoff. you want something so simple as to be useless.
if you want a read only FS, just concatenate all the files and store the offset/length pairs.

if you want something you can write to, well, your going to have to get a little complex and you know,  bust out some lines of C.

what exactly do you want, are you just pointing us to another crappy project on the internet? do you have an actual need of a embedded filesystem?

embedded filesystems are very simple until you start realising that microsd sticks and sd cards are 64gb now and managing that extra space takes extra code. when mem sticks were small and 32bit pointers were nice, things were easy.

suddenly you need more/bigger block bitmap, and your inodes end up going quadruple indirect because using 64gb of space requires lots of work.

Wandering if someone has looked at the sources in the repo 

yeah and its crap. OS_FileEntry_t is full of shit that does not need to be there making it twice as big.
its limited all over the place by uint32_t's everywhere.

it reads like a basic inode, direct block mapping with no indirect block mapping.

if you have lots of edits/deletes this thing is going to get REALLY fragmented to shit to the point you need some kind of defragmenting tool

[nctnico]

IMHO using fatfs (http://elm-chan.org/fsw/ff/00index_e.html) is the easiest way. It can be cut down to a minimalist implementation for space constrained devices.

[amyk]

embedded filesystems are very simple until you start realising that microsd sticks and sd cards are 64gb now and managing that extra space takes extra code. when mem sticks were small and 32bit pointers were nice, things were easy.

32-bit block addresses with 512-byte blocks already allows 2TB of storage, which is a lot more than most embedded applications will ever need.

Just use FAT32.

[BloodyCactus]

embedded filesystems are very simple until you start realising that microsd sticks and sd cards are 64gb now and managing that extra space takes extra code. when mem sticks were small and 32bit pointers were nice, things were easy.

32-bit block addresses with 512-byte blocks already allows 2TB of storage, which is a lot more than most embedded applications will ever need.

Just use FAT32.

your facepalm might be warranted but its not all the internal variables are 32bit, so yeah you might think 2TB... but it can only handle nearly 4gb maybe as an absolute disk size.

its also some of the worst C I've seen in a long time. putting 'logicalAND' in IF statements instead of &&. redefining C convetion ugh. this is definitely someones university homework.

[nctnico]

IMHO using fatfs (http://elm-chan.org/fsw/ff/00index_e.html) is the easiest way. It can be cut down to a minimalist implementation for space constrained devices.

that is the Petit-Fat-fs i was talking about
and it is a very "shit" code, see how terribly it is written in its inside.

It looks OK to me. Albeit it is a bit cryptic and the configurability doesn't make it easier to follow. What I do know from my own tests is that it works very well.

[nctnico]

I think we are talking about a different piece of software. The Fatfs I pointed to has a comment for about each line of code telling what it is supposed to do.

[BloodyCactus]

well, why and how you say that ? Have you checked it out ? What is no working ? Saying such a stuff is not helping me: exactly what is not working ?

Code: [Select]

- compiling app ... In file included from lib_fs_block_l3.h:5:0,
                 from app.h:8,
                 from app.c:1:
lib_media_disk.h:13:36: fatal error: lib_media_disk.interface: No such file or directory
 #include "lib_media_disk.interface"
                                    ^
compilation terminated.
make: *** [obj/app.o] Error 1

fails on the first file, not even a single file compile! total fail.

yeah and its crap. OS_FileEntry_t is full of shit that does not need to be there making it twice as big.

for example ? what to be removed ? I do not need to hear "shits", i need "advices"!

here is original, 60 bytes long.

Code: [Select]

typedef struct
{
    char_t   name[FILE_NAME_SIZE];
    uint32_t iblock;      /* first block of file */
    uint32_t modifiedTime;
    uint32_t length;
    uint8_t  isDirectory;
    uint8_t  attributes;
    uint8_t  valid;
    uint8_t  mediaType;
    uint16_t blockSize;
    uint8_t  pad1, pad2;
} OS_FileEntry_t;

here is what it should be, fits nicely in 32 byte chunk.

Code: [Select]

typedef struct
{
    char_t   name[19];
    uint32_t iblock;
    uint32_t modifiedTime;
    uint32_t length;
    uint8_t  attributes;
} OS_FileEntry_t;

an entire byte to say its a directy? fuck that. use 1 bit into attributes. for emebdded filesystem you dont even need attributes really. padding? wtf. remove the padding and add them to the filename size. block size stored per file? thats some stupid ass design for an embedded filesystem. media type per file, where its defined as ram/flash/disk/unknown? throw this shit out.

why ? It seems to me you are thinking it is a filesystem for workstation: well, it's not!

you have infinite depth sub directories, file attributes, block size per file that can change, media types?

if my 64gb SD card wont work in your device, what good is it to me? do I have to go on ebay and buy some really old 256mb card?

i am looking for such a code to be put inside an fpga SoC and MPU.

if its going to be on removable media an user user is going to manage/insert into windows etc, usb key or something, it needs to handle >4gb, be readable on windows machine. proprietary FS wont cut it. 4gb max? not good enough.

if its a filesystem for your device that nobody will see, ie only your device sees it, all this complexity of multiple subdirectories, attributes, media types, all this bullshit is not required imo.

I knocked out a simple no nothing filesystem test.