Questions tagged «hard-disk»

一种永久性数据存储设备,用于使用快速旋转的磁盘(磁片)涂覆有刚性形状因数的磁性材料(与软盘不同)来存储和检索数字信息。

5
磁盘清零时如何忽略写入错误?
假设您要将故障硬盘归零。您希望尽可能用零覆盖。您不想要的是:进程在第一个写错误时中止。怎么做? AFAICS dd仅提供了一个忽略读取错误的选项。因此,类似 dd if=/dev/zero of=/dev/disk/by-id/lousy-vendor-123 bs=128k 是不足够的。 ddrescue 似乎更容易忽略错误-但是最佳的命令行是什么? 我对GNU ddrescue的尝试: ddrescue --verbose --force --no-split /dev/zero /dev/disk/by-id/lousy-vendor-123
19 hard-disk  dd  ddrescue 

3
Docker说“设备上没有剩余空间”,但是系统有足够的空间吗?
我正在尝试运行可在其他系统上使用的docker映像(如果愿意,您甚至可以从dockerhub提取它dougbtv/asterisk),但是,在我的普通工作站上,它在抱怨可用空间(看起来像)它可以使Docker映像脱机。 我尝试运行它,当我这样做时,我收到一条错误消息,指出它空间不足。这是我尝试运行它的示例,它抱怨空间。 [root@localhost docker]# docker run -i -t dougbtv/asterisk /bin/bash Timestamp: 2015-05-13 07:50:58.128736228 -0400 EDT Code: System error Message: [/usr/bin/tar -xf /var/lib/docker/tmp/70c178005ccd9cc5373faa8ff0ff9c7c7a4cf0284bd9f65bbbcc2c0d96e8565d410879741/_tmp.tar -C /var/lib/docker/devicemapper/mnt/70c178005ccd9cc5373faa8ff0ff9c7c7a4cf0284bd9f65bbbcc2c0d96e8565d/rootfs/tmp .] failed: /usr/bin/tar: ./asterisk/utils/astdb2sqlite3: Wrote only 512 of 10240 bytes /usr/bin/tar: ./asterisk/utils/conf2ael.c: Cannot write: No space left on device /usr/bin/tar: ./asterisk/utils/astcanary: Cannot write: No space left …

2
如果发生错误,mv会做什么?
我只是试图将一棵大树从一个磁盘移动到另一个磁盘,这太小了。现在,我有一些我无法真正理解的东西-看起来确实确实从源代码树中移走了一些文件,而其他文件只是被复制了。这很可能不是事实,而且我只是忽略了一些东西,就像检查目标磁盘上的空闲空间时所做的那样。:D 命令很简单mv source-dir destination-dir,两个目录都位于不同的磁盘上。我正在使用mv (GNU coreutils) 7.4。在手册页的任何地方都找不到以下问题的答案: 截断的文件可能会被创建吗? 如果出现错误,源树中的任何内容都将被删除吗? 如何恢复(轻松快速)?
18 hard-disk  rename 


4
为什么dd需要太长时间?
我需要将一个磁盘复制到另一个磁盘。我尝试使用下面的命令,将近1天的时间在federo中复制1 TB磁盘。 dd if=/dev/sda of=/dev/sdb 我已经在Unix(HP-UX)系统上使用以下命令尝试了相同的操作,它在几个小时内完成 dd if=/dev/sda of=/dev/rdsk 我可以用来更快地从磁盘复制到磁盘的替代方法是什么?
18 hard-disk  dd 

8
在Linux中格式化硬盘的最佳方法是什么,以免留下痕迹?
我正在运行Debian,需要一种格式化整个硬盘的方式,以便不留下任何痕迹,因为我想将其捐赠给朋友。那么格式化它的最佳方法是什么?如果我重新安装操作系统,它将无法完全格式化它。我正在寻找一种完全格式化它的方法,使它像从商店购买时一样,是全新的,并且从未存储过任何东西。



3
坏扇区是否表示磁盘出现故障?
我的Ubuntu 13.10系统在过去大约一天的时间里一直表现很差。查看内核日志,看来<1yr旧的3TB SATA磁盘在特定扇区上有问题: Nov 4 20:54:04 mediaserver kernel: [10893.039180] ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Nov 4 20:54:04 mediaserver kernel: [10893.039187] ata4.01: BMDMA stat 0x65 Nov 4 20:54:04 mediaserver kernel: [10893.039193] ata4.01: failed command: READ DMA EXT Nov 4 20:54:04 mediaserver kernel: [10893.039202] ata4.01: cmd 25/00:08:f8:3f:83/00:00:af:00:00/f0 …


5
知道分区需要编辑时,可以使用“ dd”克隆到较小的HDD吗?
我曾经dd克隆过这样的磁盘: dd if=/dev/sdb of=/dev/sda bs=4096 conv=notrunc,noerror,sync 而且它始终运行良好。任何有关“ dd”的文档都会竭力提醒您,目标磁盘的大小必须等于或大于源磁盘的大小。这绝对是必须的吗? 现在,我很明白,如果我克隆到一个较小的磁盘,我不能指望 目标上甚至部分 “超出范围”的任何分区都完好无损。 但是,非常清楚我以后需要在目标上编辑分区,删除“越界”分区,我是否仍可以使用“ dd”对源进行强力复制,直至达到限制目标的物理尺寸?否则,当目标达到其大小极限时,“ dd”会将目标减少为一堆残骸;-) 顺便说一句,通过研究,我看到bs=了从bs=1024到的所有内容的推荐值bs=32M,什么才是最好的?

5
为什么在复制有限大小的设备时指定块大小?
在在线教程中,通常建议使用以下命令将CDROM复制到iso映像: $ dd if=/dev/dvd of=foobar.iso bs=2048 为什么必须指定字节大小?我注意到实际上2048是CDROM映像的标准字节大小,但似乎dd没有指定bs=或count=同样有效。 在什么情况下不指定大小bs=或count=从有限大小的设备复制会出现问题?
14 linux  hard-disk  dd  cloning 



1
磁盘(在USB机柜中)即使没有安装也不断唤醒
设定 我有USB机箱(Buffalo DriveStation Quad),其中包含连接到nas服务器(ubuntu服务器14.04)的四个驱动器。机箱已配置为JBOD模式,因此我将看到Linux中的所有磁盘。 其中两个磁盘(sdb和sdc)的软件RAID配置为/dev/md0(raid1)。并以ext4文件系统/dev/md0作为单个分区(/mnt/part1)挂载而没有日志记录。 其他两个磁盘(sdd和sde)都将LVM设置为一个卷组,从那里我已经安装了两个逻辑分区。其中之一是整个卷组容量(/mnt/part2)的90%,另一个是10%(/mnt/part3)的容量。两者都是没有日志的ext4。 APM问题 我的问题始于默认的APM模式,因为我注意到硬盘驱动器的磁头每隔几分钟就会非常激进地停下来。经过一段时间的研究,我最终使用了hdparm -B198 /dev/sd[bcde]。这似乎可以实现一定程度的节能,但实际上并不需要做任何头部停车操作。 有睡吗 我对当前的情况感到满意,但是我仍然希望驱动器在没有活动的情况下进入睡眠状态。尤其是sdb和sdc(/mnt/part1)在95%的时间内实际上没有任何活动。无论我尝试了什么,问题似乎都在于驱动器的睡眠时间不会超过一两分钟。 卸载所有分区并发布hdparm -y /dev/sd[bcde]将使驱动器进入睡眠模式,但仅持续几分钟。之后,他们都会一一唤醒。我试图通过启用block_dump(echo 1 > /proc/sys/vm/block_dump)来调试问题,但是看不到对磁盘的任何访问。 我还尝试通过禁用APM hdparm -B255 /dev/sd[bcde],并在此之后命令他们进入睡眠状态,但是还是一样。几分钟后,驱动器仍会唤醒。 我没有mdadm在守护程序模式下运行(每天只检查一次),也没有其他东西可以探测驱动器了。那么,接下来有什么想法呢?Buffalo USB机箱是否很笨拙(这是自己造成的)? 更新#1 我花了一些时间才能使磁盘在发行后唤醒hdparm -y /dev/sd[bc]。以下时间戳说明了这种模式: 00:00 hdparm -y /dev/sd[bc] 00:40 disks start to wake up 00:59 disks fully awake 01:00 hdparm -y /dev/sd[bc] 03:40 disks start to …

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.