I have OCS Vector 150
with Ubuntu 15.04
installed on it. The drive is inserted into Transcend StoreJet 25S3
closure.
It's pretty comfortable for me to use it both at home and at work. Also I can simply attach it to any PC and have my own completely configured environment everywhere.
The issue is that this solution is too sensitive to power/connection losses caused by bad usb port/bad cable/real power loss/etc... That means that if I, for example, unplug the cable during some activity with the filesystem, like file downloading/compiling/copying files/etc, I will get completely broken filesystem next time I plug the drive again. I use ext4
, but the filesystem breaks anyway. That looks like tons of errors after running fsck
. fsck fixes these errors, but it never restores all files.
Even more (un)funny that file content could be completely messed between all files which were writing during the connection loss. Actually even between files which were reading. Once, I saw that dpkg
binary contained some json, probably from firefox profile data. That makes the recovery pretty unnoing.
I try not to store any important data on the drive except that can be easily recovered.
When the armageddon comes, I use debsums
to find broken system files (when the debsums/dpkg/zsh/etc are not broken theirselves :) ), reinstall appropriate packages, and pull from my git repositories some configuration files and scripts. As the ssd drive is pretty fast, it doesn't take a long time. If the damage is not huge, it could take less than 10 minutes to recover almost everything and make the system (at least looks) clean.
So the question, after this long story, is: what do you think could be improved? I know, there hardly can be a simple and nice solution, but I would greatly appreciate if you share your thoughts on the topic.
UPDATE 10 SEP 2015 At the moment I don't think that the reason of filesystem damage is in physical impact. I use the device mostly at home and at work and statistically it damages much more often at home than at work while the activity at work includes compilation, vcs pull/commits i.e. heavy disk I/O. Once, my collegue accidentally dropped the disk from the chasis during my usual activities. It had disconnected and I thought that it would cause a serious troubles. But when I connected it back and rebooted, fsck showed no error! At the same time, at home I booted into kubuntu from this disk only for a minute, opened browser, rebooted and voila! Lost about a couple of thousands of inodes.
The symptoms are pretty simillar to these: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/992424 and https://bugzilla.kernel.org/show_bug.cgi?id=42723
I saw almost the same that those guys saw:
[11742.577091] EXT4-fs error (sdc2) ext4_mb_generate_buddy:757 group 1, block and bg descriptor inconsistent: XXX vs YYY free clusters
[11742.577337] Aborting journal on device sdc2-8
Since the issue somehow depends on machine and I don't have any other clue, I inclined to believe that the issue is somewhere in controller logic/usb power or something like that.
The question now is: how to make the filesystem more reliable? Do you think that brtfs
would help?
UPDATE 29 JAN 2016
I gave up. I took off left sides of chassis at home and at work and use SATA connections. No issues so far.