Backup, shrink partition, make new filesystem, restore.

More to the point, check out ext2resize and parted.

>How does one shrink an ext2 partition?

One usually doesn't. Instead, copy the data off, resize the partition using fdisk, and re-run mke2fs to recreate the metadata. Then copy back you saved data.

Much simpler would be to just delete the swap partition, and recreate it again 2 blocks smaller, giving you 4K of available space to play with.

Or, I could hack the kernel for you to provide a means of locating the blocks of an ext2 file on disk, so that you could re-write a file "in-situ" on a readonly filesystem. No chance of any fscking screw ups that way. To locate the file, I'd just have an ioctl() stub that invokes ext2_getblk() on the inode, which will return the block address within the partition. This can then be used as an offset for doing a write() on the raw partition (/dev/hdx), bypassing the filesystem code.

Cheers

Oh... Get Frank's modified_init package at fvgestel.dyndns.org/empeg

You put in a custom init which calls a shell script called userinit (be careful! make sure it's executable, no syntax errors etc.) Mine calls picker before it calls player. I can get you my init script if you'd like.

Yeah I'd like that.. Does yours run pick_list or just picker? pick_list would be nice. If you can send it over to my email greg@mandiola.com. Right not im kinda stuck on stuff cause i dont have a machine to compile. I do have my laptop but its slooooooow.
Thanks

-Greg

Well I was thinking more like this...

[stream of consciousness mode ON]

Instead of the user apps asking for specific blocks, there could be a lightweight API which takes as its inputs an application identifier and some kind of offset.

The app identifier would ensure that the lyrics scroller wouldn't ask for the same blocks that the OBD-II logger would ask for. Then the numeric index could be an offset, or maybe a block number within the range assigned to each application.

So let's say I've got an Empeg with my (now fictitious) lyrics scroller time tagger, the also fictitious OBD-II diagnostic logger, and the shopping list/directions thingie.

Somehow this API would read in (possibly from config.ini) a configuration for the "virtual disk" like this:
LYRICS, 16
OBD2, 64
SHOPLIST, 16

So it would give the lyrics scroller the first 16k, the OBD2 logger the next 64k, and the shopping list thing the next 16k. A call from the OBD2 logger would look like this:

empeg_storage_write("OBD2", 4, &buf)

When the storage API gets this call, it writes to the OBD2 "base" of 16k plus the 4k offset. Offsets could, of course, be in bytes or whatever for finer grain.

Obviously this is a bit more work than just an offset. I think If the kernel code was there for writing to a specific block, I MIGHT be able to string together the user code to call it properly. If not, I'm sure some other smart person could.

Does this API seem feasible? I think it would be a good way for users to have multiple apps which all would like to write data to the disk.

I don't know what pick_list is... haven't seen it yet.

My init script is on its way.

Cool thanks.. Its just a script that you can define the menu in and then it runs picker. Its included with the picker gz.

-Greg

Naw, too complex.

Just put the data into regular named files on an ext2 filesystem.
Once the files are there, and the filesystem is "readonly", we could just have a special "Open flag" to permit rewriting their data block(s) in-situ without updating any meta data (cannot change size, though).

fd = open("existing/file/path", O_RDONLY|O_SPECIAL);

read(fd, buf, sizeof(buf));

..

// modify the data in buf[]

..

write(fd, buf, sizeof(buf));

close(fd);

=========================

Sounds good... And if the power gets yanked during the write() the file is corrupted, but no filesystem damage is done.. right? That wouldn't be too bad. Just have to have a nice warning screen "do not power off the system" kind of like when console games are saving to their flash memory cards..

What about duplicating each file, and when a write is done, the first file is written, then the second. If the power is pulled anytime during this, the worst that could happen is that the file has to be reverted to the version right before it. Much better then just loosing it completly.

(Of course this needs the overhead of some sort of checksum/date stamp system to know what file is good and such.)

Yeah, error checking would be a nice thing to have, it'd be very similar to the way the flash blocks are written.

So who's gonna do all this?

No, actually I'd bet very heavily that even the file won't be corrupted. After all, it's just a disk block write, which will either succeed or fail at the drive. Laptop drives are good at detecting powerfail. Same sort of thing goes on today with the shuffle-order, mark-track, and "info-seek" "visual", all of which must write to disk to save their data. Even in car mode.

Cheers

Well yah but what about the case of a multi-block write? Couldn't some blocks succeed and others not? Obviously writing larger files wouldn't be an everyday occurrence but I could see it happening...

If you can guarantee that they'll happen in a particular order, just keep an overall CRC at the end of the block.

However, by the time you've gone this far, you've pretty much implemented a filesystem.

Well, sure, if your files are larger than 1Kb, I suppose it will depend upon the drive. But the IDE driver with Hijack sends 4KB at a time to the disk, and if you really want to scroll through a 4KB text file on a 64x128pixel screen.. well..

I think the odds of anything bad happening here are somewhere less than NIL in Real Life. And the worst that can happen is that part of your file will still have the old data, and part will have the new data. Not an issue if you organize your data structure in 1024-byte chunks.

Still simpler than a filesystem, of course, cuz we're letting ext2 keep track of directories, inodes, and block allocations. We're just adding code to "overwrite in place" on a selected file.

-ml

I agree. I think this would suit the needs of most people. I would have no problem organizing my data in 1024 byte blocks. So where might this rank in your list of things you'll be working on in Hijack?

Mark,

Re: "Simple, eh?"

I'm familiar with the everything-is-a-file philosophy of Unix and how to use it. Nonetheless, for the purposes being discussed, I stand by my suggestion that using a small filesystem is the most flexible solution, as well as being among the easiest.

A generic "small pieces of persistent data" filesystem which is mounted rw in the car would provide all applications with space, and a namespace to avoid collisions. The time to fsck e.g. a 1 meg partition is trivial... and if the file open mode is O_SYNC then the chances of data being lost due to corrupted metadata are pretty slim.

Oh well. Do as you please.

I just don't see how writing a new filesystem is easier than just using the existing ext2.

-ml

Hi Mark.

Say, did you implement some support for this yet? I mean the special flag for open() that allows in-situ overwriting of files even on R/O-mounted filesystems? This would be really great, and I guess the guys@empeg could also use that functionality for their software (like writing back some of the data about tracks to the metadata FIDs).

cu,
sven

Edit: PS: If anyone wondered how I kept the BBS from making the text "guys@empeg" into a mailto-link (like this: guys@empeg) automatically: I put a set of "< b > < /b >" (without the spaces) aroung the "@".

Edit: PS: If anyone wondered how I kept the BBS from making the text "guys@empeg" into a mailto-link (like this: guys@empeg) automatically: I put a set of "< b > < /b >" (without the spaces) aroung the "@".

Sven, you sly dog, you...


tanstaafl.

>Say, did you implement some support for this yet?
>I mean the special flag for open() that allows in-situ overwriting..

Not there yet. I am waiting to see if it's just so much hot air like some other "desperately needed" features have been in the past.

But I think this could be a really cool extension even for stock ["blessed with holy Torvalds penguin pee"] kernels.. so maybe I'll look at it and do a nice job on it. Someday..

Cheers

Yeah I was using that trick to avoid my smileys :) being turned into gay pictured emoticons But I got sick of doing it all the time. I'm succumbing to the lameness of the forum software... sigh. You can only "fight the man" for so long.

being turned into gay pictured emoticons

The emoticon prefers the term "jovial".

"Not that there's anything wrong with that..."

I can think of several other things to do with a small (1M) RW fs.

For small files, it's faster to sync a Palm than an empeg. For things like directions, it's easy to put them in your Palm and it'd be nice to be able to send text files from the Palm to the empeg. This would also be handy for people who leave their empegs in their cars, but carry their Palms with them. I know this requires IrOBEX and without that available in Hijack, it doesn't seem like a likely use.

When the OBD-II gang gets farther along, it will be nice to write to log files for permanent storage. This data could be used to generate graphs for display on the empeg or via khttpd (mrtg style).

GPS data would also be nice to save to log files. You could use this to plot graphs of places you've been, distance travelled, etc.

I'd even find a history of when the empeg's been on in home/car mode interesting. From those logs, I'd be able to tell how much time I spend driving on an average day.

I'm sure there's other uses too. Between those things and wanting more graphics for khttpd to serve up, I'm thinking of popping a 2nd HD in there to store my own data on ext2 fs's.

TFabris: The emoticon prefers the term "jovial".

Ummm, actually I'd prefer the term "Hot-Ass Chick"

Emoticon
Ubiquitous Internet Utilities, LLC

GPS data would also be nice to save to log files.

FWIW, Kim's GPS project currently does this. It uses a rw mounted partition for swap, log files, configuration, etc.

It seems like many people are asking for a place on the empeg they can write to for various reasons and we have that spare 32? meg partition. Why don't we just use it? fsck times for a partition that small are trivial so even if it gets fsck'd every time it isn't that big a deal as long as apps are prepared to occasionally loose data written to it. Of course if we could ext3 it that would be even better.

-Mike

Okay folks i still know nothing about programming but i know we have ftp with hijack can we do this idea for my shopping list plan?

I think I could implement something like what you described without excessive trouble. (I'm always up for fun little programming projects anyway.) I'm finishing up something else I'd like to have done for my own use though, (ran to a minor snag that I'm hoping mark can help with last night) so give me a few days and I'll see what I can do.

John

That from Ask Jeeves?

- Trevor