- SORFC -
Request for comment and coding: WRAP-Device
-------------------------------------------
WHAT (summary)
----I suggest the design of a wrap-device, which puts data given per write() on another media and, if the end is reached on this media, wraps around to the beginning. On reading the ordered list of completly existing blocks is given back.
HOW (semantics) ---
1) open O_APPEND: starts writes after the last written block. O_WRONLY: purges the entries and starts from beginning. O_RDONLY: reads the existing blocks.
2) seek - in both write cases (O_APPEND & O_WRONLY), seek() can be used to write EOF-markers (with a positive offset seek()) (like on a tape). - in O_WRONLY mode, seek() with negative offset purges and restarts. - in O_RDONLY mode, seek() goes blockwise.
3) locking it must be possible to set a write-lock on a written buffer, so that it can be garanteed to persist until the lock has been released. if the media wraps around to a locked position, all writes must be stalled.
3) ioctl (or other mechanism?) to set some flags. - option compressed: the header-data per write doesn't get a whole block; instead, the user-data is written immediately after the header. (slower, saves space with small entries). - if possible to use two or more media. so I put eg. 2 tapes in my server; all writes go to the first, until it is full; then, while the first is rewound, the 2nd is written to. if this gets full, the first is used again
4) wrapsetup similar to losetup - wrapX-device - media (/dev/ram, /dev/hdf, /dev/hdc3, /dev/tapeX [?]) - create or delete - some flags
5) other details - first block on the media should be used to store some statistics ("superblock"). on every wrap-around it is rewritten (no penalty) to store the position of the first headerblock in the file.
the header-blocks store: - signature (?) - header-len - data-len - pointer to next header (current + header-len + user-header-len + data-len) - pointer to previous header - timestamp - user-header-len - user-header
"first" valid data v |-|--------------|--|---------|--|----------|---------------|--|--| |S|D1 (continued)|H2|D2 |H3|D3 |xxxxxxxxxxxxxxx|H1|D1| |-|--------------|--|---------|--|----------|---------------|--|--| ^ ^ mark current position
S is Start of media with "superblock" H? are header-blocks, D? the corresponding data-blocks.
as H1/D1 were written, a wrap-around occured. so the "superblock" is written again, with an pointer to "mark" - from where (by means of double linked list) every other (valid) header can be reached.
user-header can be used to store (eg) - user-id for block - fs-id in header-block (to store more than 1 fs-journal onto the same media) - commit for another blocks
What I'm not sure about is, if user-header should be put per - ioctl(). Could be used to return current statistics (position on media) at the same time. - per seek() to special offset - per write with special signature at start (NO!NO!) - some kind of Out-of-band would be useful.
WHY ---
ext3 needs (and already has) a similar thing, all journaling fs could use a sane, central architecture. So something like this HAS to be in the kernel. And it should be a kernel part to avoid multiply copying in memory.
In user-mode it could be used to store eg. the last 2 minutes of sound; occasionaly recording stops and another file could be started.
WHO ---
As I'm already working on another super-secret project (for which I'm very likely to need help RSN :-) and this work has mostly already been done, I hope for a volunteer to step forward and declare himself. Thank you!
WHEN (timeline) ----
I hope this makes it in 2.5.x (x<5) and 2.4.y (y<10), as this could be very useful for all journaling fs.
- EORFC -
Thank you for any comments!!!
Phil
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:10 EST