| 1 |
Storing data on a dvd is always quite useful and dvds cost much less than usb |
| 2 |
keys or other... I've been thinking about one thing. |
| 3 |
|
| 4 |
Is there any such thing as an incremental filesystem for write-once-read-only |
| 5 |
media (ie. DVD+-R)?... |
| 6 |
|
| 7 |
A filesystem that would append the inode table at the end of the session at each |
| 8 |
session, and the table would refer to previous dvds, only the last table would |
| 9 |
be read, previous tables ignored (unless used for journaling)... This would |
| 10 |
make that after some time of usage if you wish to copy certain files back to a |
| 11 |
hd, the filesystem would have to instruct you to insert a specific series of |
| 12 |
dvds in order to extract all those files (or blocks). This of course will |
| 13 |
clearly result in waste and large number of dvds if used a lot in read-write |
| 14 |
operations (ie, nothing gets ever rewritten but instead can be no longer |
| 15 |
referenced by the table). |
| 16 |
|
| 17 |
I've been thinking on hacking the ext2 kernel driver to support this kind of thing. |
| 18 |
|
| 19 |
Of course the goal with such filesystem is for backup of individual files, but |
| 20 |
since I would be using something like a modified ext2fs, a very large file could |
| 21 |
be spread on multiple dvds, be fragmented and stored this way transparently. |
| 22 |
|
| 23 |
Another way might be to use a read-writable media for storing the fs table. |
| 24 |
Possibly, using a modified ext2fs which would transparently work like a real |
| 25 |
ext2fs, a tool like rsync could be used to make true incremental backups using |
| 26 |
the hard-links trick. But it could also be used like a rarely used hard-drive |
| 27 |
which does not suffer from magnetic deterioration (however unlikely this is). |
| 28 |
|
| 29 |
Any such tool? |
| 30 |
If not, this would be my first project dealing with kernel programming. |
| 31 |
|
| 32 |
Simon |
| 33 |
|
| 34 |
Florian Philipp wrote: |
| 35 |
> meino.cramer@×××.de schrieb: |
| 36 |
>> Hi, |
| 37 |
>> |
| 38 |
>> since I own a LG HD-LT-DT GSA-4163B bruner, which |
| 39 |
>> allows to burn DVDRAM discs I try to generate a |
| 40 |
>> setup, which successfully writes data to a DVDRAM. |
| 41 |
>> |
| 42 |
>> Everything else works fine. But writing a complete DVDRAM |
| 43 |
>> takes "hours". As recommended I use UDF as the filesystem |
| 44 |
>> of choice -- no unnessary rewrite of the same sectors of |
| 45 |
>> the DVDRAM. |
| 46 |
>> |
| 47 |
>> I tried to use packet-writing but ot does not help. |
| 48 |
>> |
| 49 |
>> Is there any "definite" recipe how setup everything to |
| 50 |
>> get any reasonable transfer rate to and from the DVDRAM |
| 51 |
>> or is it simply not possible with Linux? |
| 52 |
>> |
| 53 |
>> Any help is very appreciated -- thank you very much in advance! |
| 54 |
>> mcc |
| 55 |
>> |
| 56 |
> |
| 57 |
> I've given up packet writing a long time ago. It never worked for me. |
| 58 |
> |
| 59 |
> IMHO both udftools and the kernel driver are not really usable (just try |
| 60 |
> udffsck ...) and with the advent of flash memory I don't think anyone |
| 61 |
> will invest a lot of work in either one. |
| 62 |
> |
Archives