我有一个目录，其中包含来自外部源的约 10,000 个图像文件。
许多文件名包含对 DB 或 Web 不友好的空格和标点符号。我还想在每个文件名的末尾附加一个 SKU 编号（出于会计目的）。许多（如果不是大多数）文件名还包含扩展的拉丁字符，我想保留这些字符用于 SEO 目的（特别是文件名准确地代表 Google 图片中的文件内容）
我制作了一个 bash 脚本，它将所有文件重命名（复制）为我想要的结果。bash 脚本以 UTF-8 格式保存。运行后，它省略了大约 500 个文件（无法统计文件...）。
我已经在目录上运行了convmv -f UTF-8 -t UTF-8，发现这 500 个文件名不是用 UTF-8 编码的（convmv 能够检测并忽略已经在 UTF-8 中的文件名）
有一个简单的办法，我可以找出哪些他们目前正在使用的语言编码？
我能够弄清楚自己的唯一方法是将我的终端编码设置为 UTF-8，然后使用 convmv 遍历所有可能的候选编码，直到它显示一个“看起来正确”的转换名称。我无法确定这 500 个文件都使用相同的编码，所以我需要重复这个过程 500 次。我想要一种比“看起来正确”更自动化的方法！！！
当 SAN 出现问题时，ext3 检测磁盘写入错误并以只读方式重新安装文件系统，这是一个相对常见的问题。这一切都很好，只有当 SAN 修复后，我才能弄清楚如何在不重新启动的情况下重新安装文件系统读写。
看：
[root@localhost ~]# multipath -ll
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=2][active]
\_ 1:0:0:1 sdb 8:16 [active][ready]
\_ 2:0:0:1 sdc 8:32 [active][ready]
[root@localhost ~]# mount /dev/mapper/mpath0 /mnt/foo
[root@localhost ~]# touch /mnt/foo/blah
一切都很好，现在我从它下面拉出 LUN。
[root@localhost ~]# touch /mnt/foo/blah
[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system
[root@localhost ~]# tail /var/log/messages
Mar 18 13:17:33 localhost multipathd: sdb: tur checker reports path is down
Mar 18 13:17:34 localhost multipathd: sdc: tur …当对磁盘的 SMART 检查报告坏扇区时，重要的是能够识别具有坏扇区的文件 - 并从备份中恢复它。下面，我展示了我是如何为我的 Linux/ext3 VMWARE 服务器做到这一点的——但有没有人知道这是否可以为 Windows/NTFS 做到这一点？
以下是我为 Linux/ext3 所做的：我首先要求驱动器进行硬件表面扫描（低于操作系统级别，使用驱动器上的 SMART 电路）：
vserver:~# smartctl -t long /dev/sdc
我看了结果：
vserver:~# smartctl -a /dev/sdc
...
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 1
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 9
...
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed: read failure 90% 27679 591363172
因此，一个扇区已经被标记为坏，9 个被标记为从“暂存”扇区空间替换。更重要的是，第一个不可读的逻辑块地址 (LBA) 是 591363172。
我找到了这个数字“转换”为的分区（以及其中的偏移量）：
vserver:~# fdisk -lu /dev/sdc
Device Boot Start End Blocks Id System …我在这个主题上看到的最后一个真正的问题是大约两年前的（ext4 是否已准备好用于生产）。
在此期间，ext4有何改进？
XFS、JFS和ext3是备用的可靠选择。我只在最近的 Ubuntu 测试/开发环境中使用了 ext4，并没有发现任何问题 - 但它们也是低使用率的工作站、VM 和一次性培训环境。
从速度和可靠性的角度来看，ext4 与 XFS 和 JFS（尤其是）相比已经有 [一些] 时间成熟，现在它如何叠加？
我使用 rsnapshot 为我的“工作”共享创建每小时/每天/每周/每月的备份。现在我正在尝试使用 rsync 将整个备份目录复制到外部驱动器上。
我在屏幕会话中使用了这个命令/参数（是的，rsync-exclude.txt 位于我运行命令的目录中）
rsync -avzHP --exclude-from 'rsync-exclude.txt' /share/backup/ /share/eSATADisk1/backup/;
整个东西在QNAP TS-439上运行，内部驱动器是一个格式化为EXT4的单盘（无RAID），外部驱动器是格式化为EXT3。
发生的情况是：Rsync 跟随每个硬链接并且 复制实际文件，而不是在外部驱动器上重新创建更新的硬链接。我没有立即意识到这一点，因此外部驱动器最终被相同文件的 xxx 副本丢弃。
我想要实现的是：将 rsnapshot 生成的整个文件结构复制到外部驱动器，保留硬链接以节省空间。注意：这不一定是使用 rsync 完成的。
感谢您的想法和时间。我很感激你的帮助，很重要。
更新：我了解到，rsnapshot 不使用符号链接，它使用硬链接，所以我现在使用 -H 选项，它应该根据Rsnapshot 保留硬链接结构到多个目的地（或维护硬链接结构），但它仍然不起作用......我在这里错过了什么？
更新 2：我在这里找到了关于这个主题的另一个意见/声明：rsync with --hard-links freezes Steven Monday 建议不要尝试 rsync 包含硬链接的大文件结构，因为它会占用大量内存，这对 rsync 来说是一项艰巨的任务。所以可能更好的解决方案是制作我要备份的数据结构的 .img。你怎么认为？
我照顾着一个只有 512 MB 内存的旧 Debian linux 机器（运行 etch），但连接了很多外部存储。一个 ext3 文件系统的大小为 2.7 TB，fsck 无法检查它，因为它内存不足，出现这样的错误：
分配目录块数组时出错：内存分配失败 e2fsck：中止
我已经添加了一个 4 GB 的交换分区，但它仍然没有完成，但这是一个 32 位内核，所以我不认为添加更多会有所帮助。
除了启动到 64 位内核之外，还有其他方法可以让 fsck 完成它的检查吗？
据我了解，类 Unix 操作系统上的每个文件都有一个 inode 编号（可以用“ls -i”查看），每个 inode 是一个包含文件实际数据的磁盘块列表。
是否有一个 Linux 命令将文件名作为其参数并打印出该文件的 inode 指向的磁盘块列表？
PS 有问题的文件系统是 ext3。
我们一直在托管公司的 VM 上运行服务器，并且刚刚注册了专用主机（AMD Opteron 3250，4 核，8GB RAM，软件 RAID 中的 2 x 1TB，ext3）。
在运行性能测试时，我们注意到一些 SQLite 转换（插入、删除和/或更新的组合）比我的 2010 MacBook Pro 花费的时间长 10 到 15 倍。
经过大量的谷歌搜索和阅读，我们开始查看挂载选项，它们是：
data=ordered,barrier=1我们做了一些实验，并获得了最佳性能
data=writeback,barrier=0我已经阅读了这些内容，并了解他们正在做的事情的基础知识，但我对我们这样跑步是否是个好主意没有很好的感觉/感觉？
对于托管服务，上述配置是否明智？
如果我们遇到停电或严重崩溃，那么我们最终可能会丢失数据或文件损坏。如果我们每 15 分钟拍摄一次数据库快照，这可能会缓解这种情况，但拍摄快照时数据库可能不会同步。我们应该（可以？）如何确保这种快照的完整性？
我们应该考虑其他选择吗？
谢谢
我的公司制造了一个嵌入式 Debian Linux 设备，它从内部 SSD 驱动器上的 ext3 分区启动。由于该设备是一个嵌入式“黑匣子”，它通常以粗鲁的方式关闭，只需通过外部开关切断设备的电源即可。
这通常是没问题的，因为 ext3 的日志记录使事情井然有序，所以除了偶尔丢失部分日志文件之外，事情一直在顺利进行。
但是，我们最近看到许多单元在经过多次硬电源循环后，ext3 分区开始出现结构性问题——特别是，我们在 ext3 分区上运行 e2fsck，它发现了许多类似的问题显示在此问题底部的输出列表中。运行 e2fsck 直到它停止报告错误（或重新格式化分区）会清除问题。
我的问题是……在遭受大量突然/意外关闭的 ext3/SSD 系统上看到这样的问题有什么含义？
我的感觉是这可能是我们系统中软件或硬件问题的迹象，因为我的理解是（除非出现错误或硬件问题）ext3 的日志记录功能应该可以防止此类文件系统完整性错误。（注意：我知道用户数据没有被记录在日志中，因此可能会发生被删除/丢失/截断的用户文件；我在这里专门讨论文件系统元数据错误，如下所示）
另一方面，我的同事说这是已知/预期的行为，因为 SSD 控制器有时会重新排序写入命令，这可能会导致 ext3 日志混淆。特别是，他认为，即使在正常运行的硬件和没有错误的软件的情况下，ext3 日志也只会降低文件系统损坏的可能性，并非不可能，因此我们不应该对时不时地看到这样的问题感到惊讶。
我们谁是对的？
Embedded-PC-failsafe:~# ls
Embedded-PC-failsafe:~# umount /mnt/unionfs
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Invalid inode number for '.' in directory inode 46948.
Fix<y>? yes
Directory inode 46948, block 0, offset 12: …