Hello,
rough summary of my goal: Caching filesystem which does not require
access to the underlying block device, has no data losses, encrypts
stuff nicely and doesn't crash.
longer version:
I am currently using two computers, a notebook and a (former)
desktop, now mainly serving as a file server.
When at home, I dock the notebook (Thinkpad T410s, only 128 GB HDD)
into the docking station, which triggers a script to run which
basically has this layout:
IF is_docked THEN
mount_sshfs_on_desktop();
setup_xrandr();
enable_backups();
ELSE
IF (! umount_sshfs_on_desktop() == SUCCESS) THEN
kill(sshfs);
FI
setup_xrandr();
disable_backups();
FI
So if I am docked, it mounts a directory on the desktop and sets up
the screen, if undocked, it tries to unmount said directory and kills
the associated process, if necessary. This script is also run on
resume, so changes while the system was suspended will be handled
properly. Everything works. :)
There is also a regular backup taking place if I am at home, which
uses rsync to the desktop to backup my data.
I also use the desktop to play music when at home, it does so using
the data on its hard drives.
Now I want to replace that desktop with an external hard drive which
does RAID-1 internally and has an e-SATA port, which I'd connect to
my docking station.
So each time I dock the notebook, it has to
a) find the new hard drive
b) setup the encryption (LUKS, probably) on it
c) mount it somewhere
d) connect GMPC to the remote MPD
e) allow backups to take place
This is rather easy. However, undocking also has to work and the
tricky part is that I don't want to run a script before undocking but
only after the signal was received, i. e. I want to be able to grap
the notebook and leave (and not enter a command, wait, grab the
notebook, leave).
It basically has to do:
a) disallow backups, cancel any running backups
b) connect GMPC to the local MPD
c) unmount the filesystem
d) close the encryption device
e) be happy
I imagine c & d difficult to achieve without fearing serious data
corruption or even a system crash.
I also would like everything to work out nicely with suspend/resume,
but I guess running the undocking-scripts before suspend should be
enough to do so.
I actually don't even know if LUKS-encrypted devices have to stay
online as long as the mapped device exists, i. e. if its only a
filesystem or also a LUKS problem.
Therefor, I assumed that avoiding LUKS would be a sane idea, making
other kinds of encryption necessary. And here comes the file system
mentioned above:
A filesystem that is given a block device and maybe some sort of
write-cache, which handles sudden disappearance of said block device
nicely, which encrypts my data, which also maybe blocks all read
requests to the device/filesystem (and, ideally, caches the write
requests) while the block device is offline. I wouldn't mind it to
cache the directory tree, so moving files or checking if a specified
file exits would be possible. If one tried to access a file not
currently accessible (because it isn't cached anywhere and the block
device is missing), it could print out a meaningful error message or
something.
Possible solutions I thought of:
+ Unison: seems to require the underlying block device to be always
present
+ git-annex: Would normally be suited quite well, but it seems to
lack the usual filesystem tree. I would also like it to recover
remote (i. e. blockdevice) content automatically upon access. I
don't know if Sharebox does this (it seems to do so) and how it
would would work with disconnected remotes.
+ some imaginary file system I thought of above :)
Do you have any ideas on how to do this? How do you handle your
external hard drive with all your data? :)
Best regards and thank you very much for reading this post,
Claudius
--
<f00Dave> Look, rejects, this is #OpenGL, not #GEEKSEX.
Please use GPG: ECB0C2C7 4A4C4046 446ADF86 C08112E5 D72CDBA4
http://chubig.net/ http://nightfall.org
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110616212457.3a992...@ares.home.chubig.net
