-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eben Eliason wrote: | In other words, the Journal and the interactions with it are so tied | to the system already, that one would still have to manually copy | pretty much anything one wants onto the SD card or external device | anyway. The only difference would be in whether or not the copied | files get indexed, with metadata, similar to the way the Journal | entries do; it can never serve as a "replacement" for the Journal, or | as an "extension" of it, which seems to remove most of the benefits | that it could otherwise offer. Perhaps you could instead "register" | an SD card *as* the Journal, so that in the future the Journal | activity ignores NAND and instead operates only on the registered | device instead. This doesn't really extend the memory...it simply | swaps it out (for something with, presumably, much more), which is | still not that great.
To me, this issue seems almost indistinguishable from the school-server Journal integration problem. In both cases, we have a storage device other than the NAND, providing a great deal of space (potentially larger than the NAND) but whose presence is not entirely dependable. The comparison is particularly apt if we imagine a scenario in which there are multiple backup servers, some trusted and some not, as suggested in Bitfrost. The role of a specific SD card could then be as (1) Trusted Journal storage, (2) Untrusted Journal storage, or (3) Non-Journal storage. The mechanisms required for handling removable media, USB hard drives, and networked storage, are all essentially the same. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIF+ndUJT6e6HFtqQRAu85AKCbTJ87WMPKAHi72cbaJsFac+uoNACdGGVy W9/X7JwZYiyQW4U0h3DLK8I= =S8Im -----END PGP SIGNATURE----- _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
