The Doctor <dr...@virtadpt.net> posted 4978b84a.6080...@virtadpt.net, excerpted below, on Thu, 22 Jan 2009 13:17:46 -0500:
> I just gave it a try with a 32 megabyte SD card on my laptop. 32 megs? That's small! How old is it? I looked at that and thought to myself "typo, he must have meant gigs", but then I saw the below... > ...but I wasn't able to create a ReiserFS file system: > reiserfs_create_journal: cannot create a journal of 8193 blocks with 18 > offset on 7456 blocks > > Oops. Too small a device, I guess. So, I tried EXT3: Yes, it must have been 32 meg. reiserfs uses a 4k blocksize by default, and as it mentions, an 8193 block journal, again by default. That's about... 32 MB. So yes indeed, you'd have problems fitting that on a 32 MB device -- it'd be all journal! There are parameters you can add to mkfs.reiserfs/mkreiserfs to change both the block size (-b, 512 byte to 8k, 4k default) and the journal size (-s, 513-32749 blocks, default 8193), thus yielding a minimum journal size of 256.5kb which would have easily fit, but you'd not be expected to know that since you don't run it routinely, and even many who do probably don't know it. BTW, due to reiserfs' dedicated journal (hidden) file, the fact it can't be disabled (tho it can be on a separate device) and the frequency it'll be written, I don't believe reiserfs is particularly suitable for flash based media. But for much the same reason, no traditionally journalled filesystem, where journalled means rewriting the data twice, is particularly suitable for flash. So ext3 is out as well, tho ext2 will work. The modern alternative, as implemented by reiser4 and now btrfs (I believe), isn't journaling per se, but what is called wandering trees, write the data once and then migrate the metadata up the tree. But even that's not the best for flash. Logging filesystems, which continuously write new data appended to the end of the old data, to the size of the volume before scrubbing deletions and etc, work better, since they don't rewrite anything until the entire volume is full, then they rewrite and compress the data toward the beginning of the volume, and start appending again, so no blocks are ever worn out more than a single cycle more than the rest of the device, depending on where the current log-writing pointer is located. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
