Drobo文件系统忽略/etc/fstab，在连接中断后自动进入错误的位置

Question

我在Linux上的三个分区中有一个Drobo，它会周期性地丢弃文件系统，失去其挂载点。返回后，它忽略了/etc/fstab，并将其安装为/media下的新设备--就像我插入了一个新的USB棒一样。

AFAICT，fstab声明是正确的--它们是手动工作的--但是也许我漏掉了一个关键元素：

# drobo mount points
UUID="d4af52ec-7734-4a43-91cf-ccea799b130e" /mnt/d1 ext3 rw,user 0 2
UUID="599456dd-3e9e-4f56-aa8e-957191099c6b" /mnt/d2 ext3 rw,user 0 2
UUID="94a0b9bf-6ae3-45cf-9a66-da228da64660" /mnt/d3 ext3 rw,user 0 2

Drobo不干净地退出，产生了大量的假副本。唯一的硬件是一个内部驱动器和Drobo。

gvfsd-fuse   on  /run/user/1000/gvfs       type  fuse.gvfsd-fuse  (rw,nosuid,nodev,user=zed)
/dev/sde2    on  /mnt/d1                   type  ext3             (rw,noexec,nosuid,nodev)
/dev/sdf2    on  /mnt/d2                   type  ext3             (rw,noexec,nosuid,nodev)
/dev/sdg2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev)
/dev/sdd2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sdc2    on  /mnt/d2                   type  ext3             (rw,noexec,nosuid,nodev)
/dev/sdb2    on  /mnt/d1                   type  ext3             (rw,noexec,nosuid,nodev)
/dev/sdh2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev)
/dev/sdi2    on  /mnt/d1                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sdk2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sdj2    on  /mnt/d2                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sdn2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sdm2    on  /mnt/d2                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sdl2    on  /mnt/d1                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sdo2    on  /mnt/d1                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sdp2    on  /mnt/d2                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sdq2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sdt2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sds2    on  /mnt/d2                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sdr2    on  /mnt/d1                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sdz2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sdy2    on  /mnt/d2                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sdx2    on  /mnt/d1                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)
/dev/sdu2    on  /media/zed/drobo1         type  ext3             (rw,nosuid,nodev,uhelper=udisks2)
/dev/sdw2    on  /media/zed/drobo3         type  ext3             (rw,nosuid,nodev,uhelper=udisks2)
/dev/sdv2    on  /media/zed/drobo2         type  ext3             (rw,nosuid,nodev,uhelper=udisks2)

当我(手动)卸载和重新挂载时，它遵循fstab声明，没有问题。我不需要第一次输入umount /mnt/d*。我不需要重新上马。

手动卸载命令工作得很快。第一个重新挂载命令需要几秒钟时间，Drobo就会恢复(我想这是Drobo允许驱动器休眠，但是Drobo本身仍然在文件系统上)。第二次和第三次挂载命令总是以我所能键入的速度最快。

0 [08:57:46 zed@linnicks doc 124] umount /media/zed/drobo*
0 [08:57:51 zed@linnicks doc 125] mount /mnt/d3
0 [08:57:56 zed@linnicks doc 126] mount /mnt/d2
0 [08:57:59 zed@linnicks doc 127] mount /mnt/d1
0 [08:58:01 zed@linnicks doc 128] 

我错过什么明显的东西了吗？

我主要关心的是为什么忽略了/etc/fstab，尽管我最好首先找出产生这种情况的根本原因**。就在刚才，我突然意识到，克伦可以重新上马，但这更像是一种创可贴。

我们很容易将2008年的Drobo事件归咎于偶尔出现的故障。这看起来完全是随机的。Drobo将在一周或三周内正常工作，然后只是在错误的地方。它总是三个分区。我和其他机器人的运气不太好，所以我很快就把掉水的事归咎于drobo --也许我在那里太匆忙了。值得注意的是，理论上我的操作系统应该识别硬件，而不是每次将其定义为三台新设备。

我不认为Drobo只是进入了睡眠模式，因为我可以一、两天不使用它，然后直接回到它。

**从后备的角度来看，这种模棱两可可能会引起更深层次的关注，但我正计划进行一次更好、更传统的RAID，作为额外的备份。"RealRaid“上的所有内容都将由Drobo三重处理，所以当其中任何一个死亡时，我都会替换它并继续前进。请注意，如果有人发现了一个特定的装置(Qnap，Lacie.)在消费者(甚至是消费者)的层次上，保持高度的满足感。我想应该在15-30 the的范围内。

Answer 1

我主要担心的是为什么/etc/fstab被忽视了.手动安装立即将它们放回应有的位置。

所指的自动安装是由udisk执行的。正如您所希望的那样，如果有这样的条目的话，它应该服从于/etc/fstab中的条目。但是如果没有，它就安装在/media下面。听起来udisk被失败(但仍然存在)挂载弄糊涂了.我会说这是udisk中的一个bug。如果您有兴趣看到它的改进，那么请向项目报告:)。

Udisk实际上已经通过设备删除进行了测试，因为这是真正的用户所做的事情:)。如果udisk挂载文件系统本身，并且删除设备，它将尝试卸载文件系统并进行清理。无论是否在/etc/fstab中手动指定挂载点，都会发生此卸载。但是，如果设备是使用/sbin/mount“手动”安装的，udisk不会自动卸载。

因此，当udisk开发人员进行初始编码/测试时，您的场景不一定会被注意到。

注意，手动运行mount /dev/sdu2与插入“新”设备时发生的自动操作不同。/sbin/mount不打电话给udisks。(udisks可能是用/sbin/mount实现的)。