Okay, here's what I know so far about the default partitions available on the Empeg. Someone correct me if I'm wrong about any of this

empeg:/# cat /proc/partitions
major minor  #blocks  name

   3     0   17716608 hda
   3     1          1 hda1
   3     2      33264 hda2   ext2 partition for user stuff 
   3     3      16632 hda3   ???? partition for settings, playlists, etc
   3     4   17633448 hda4   ext2 partition for /drive0 (music) 
   3     5      16569 hda5   ext2 root partition 
   3     6      16600 hda6   swap partition 

So here's what I'm not certain of. I've read several times that the disks are mounted read-only and kept spun down most of the time, etc. But if hda3 is a dynamic partition that stuff is written to (playlists and such) how is it kept read only? Also, I've read that it's some custom Empeg filesystem type, and "is not suitable for developer use." That's okay, but is there any way to *read* the contents? I was looking for a way I could drop to a shell and get the name of the song that was currently playing in the player (from this partition) and then find the corresponding FID file and delete it with a script. Like I know the "mark track" feature is coming, but until then, I thought I could quit the player to a shell and run a script to delete the currently playing tune. To do this it seems I'd need to be able to read something from /dev/hda3.

So regardless of whether that's possible or not, can someone tell me what the deal is with this partition? If the drives are kept read only, I'm a little confused as to how data gets to this guy.


-Tony
MkII #554

Partitions are always read/write; the ext2 partitions are *mounted* read only. /dev/hda3 is not ever "mounted", we deal with it ourselves, using it at sector level.

You can open a block device as you would any other file, but (ISTR) you need to start any i/o requests at sector boundaries, though the lengths you request don't have to be sector multiples.

The partition doesn't store the currently playing file, just the current playlist - the index into the playlist is stored in /dev/empeg_state. The problem with us documenting this is that we treat it as internal data and we change it regularly - 1.1 uses the partition differently to 1.01 for example. Deleting the currently playing fid may well be problematic, as you'd have to remount the partition when it had files open (which it may well not let you do).

Hugo

assuming I would manage to
- resize hda4 (make it smaller) without harming the ext2fs in any way
- move hda5 and hda6 "up" by the amount I just shrunk hda4
- create a new hda7 in the free space

Would that bother the player at all ?
(I assume it just reads the partition table and then uses the (standard?) ext2fs-driver.)

If I break the player in the process (e.g. ruining the partition-table or killing the fs on hda4/5/6)
will I be able to rescue it ? Easily ?

Why ?
I would prefer to have all my "applications" on a seperate partition.
And maybe have a small partition with a journaled fs for dynamic data.

just a thought
anti

When you upgrade the player, it rewrites the partition table; it's not a good idea to change it, everything will break horribly.

If you need space, use /dev/hda2 or create a directory on the music partition otherwise you won't be able to use upgrade files without trashing the unit.

Hugo

Durring an upgrade does the installer touch the partition table of the second harddrive?


-Finally received my Mark2 no thanks to customs.

Not at the moment, no.

Hugo

Apropos journaled filesystem....

http://slashdot.org/features/00/10/13/2117258.shtml

Sounds nice, as it's an extension for the ext2fs.




Lars