Soru işaretleri dizinin ls olarak gösterilir. IO hatalar da
Bunu daha önce gören var mı? Sunucuma bir raid 5 monte ettim ve herhangi bir nedenle bunu göstermeye başladı:
jason @ box2:/mnt/raid1/cra $ ls -alh ls: e6eacc985fea729b2d5bc74078632738: Giriş/çıkış hatası ls: 257ad35ee0b12a714530c30dccf9210f [çıkış: hatası: toplam 0 drwxr-xr-x 5 kök kökü 123 2009-08-19 16:33. drwxr-xr-x 3 kök kökü 16 2009-08-14 17: 15 .. ?????????? ? ? ? ? ? 257ad35ee0b12a714530c30dccf9210f Drwxr-xr-x 3 kök kökü 57 2009-08-19 16:58 9c89a78e93ae6738e01136db9153361b ?????????? ? ? ? ? ? e6eacc985fea729b2d5bc74078632738
Md5 dizeleri, hatanın bir parçası değil, gerçek dizin adlarıdır. Soru işaretleri gariptir ve soru işareti olan herhangi bir dizin/delete/etc komutunu kullanmaya çalıştığınızda bir io hatası atar.
"Meşgul" nedeniyle sürücüyü umount edemedim. Sunucunun yeniden başlatılması "düzeltildi" ama kapanırken bazı baskın hataları atıyordu. İki baskın 5 dizisini yapılandırdım ve her ikisi de rastgele dosyalarda bunu yapmaya başladı. Her ikisi de aşağıdaki yapılandırmayı kullanıyor:
mkfs.xfs -l boyutu = 128m -d agcount = 32 mount -t xfs -o noatime, logbufs = 8
Çok süslü bir şey yok, ancak bu kutu için optimize edilmiş bir yapılandırmanın parçası. Sürücüleri bölümlere ayırmıyoruz ve bu olası bir sorun olarak önerildi. Bu suçlu olabilir mi?
Dizinin okuma (r) vardı ama (x) haklarını yürütmediği için benzer bir sorun vardı. Rehber listem gösterildi:
[email protected]:/home$ ls -l service/mail/
ls: cannot access service/mail/001_SERVICE INBOX: Permission denied
total 0
-????????? ? ? ? ? ? 001_SERVICE INBOX
d????????? ? ? ? ? ? 01_CURRENT SERVICE
Posta dizininde r biti ayarlandı, ancak listeleme veya arama ve erişim için gereken x ayarlanmadı. Sudo chmod -R g+x mail Yapmak bu sorunu çözdü.
ls çıkışındaki soru işaretleri sadece dizin girişini stat() yapamayacağını gösterir. Ayrıca r(ead) ancak x (arama) iznine sahip olduğunuz bir dizine ls sahipseniz bunları da görebilirsiniz. G/Ç hatası.
Sizin durumunuzda bir disk hatası veya muhtemelen dosya sistemi bozulması varmış gibi görünüyor. /var/log/messages veya dmesg daha fazla ayrıntı gösterecektir.
Okumadan söz eden, ancak execute veya stat () yanıtı doğru. Ancak bunun birkaç kez ısırılan ve sorunuzu IO hatalarıyla güzel bir şekilde eşleştiren) yaygın bir nedeni (yolsuzluk dışında) var. Yeni bir dosya sistemi kurmayı denediğiniz yerlerde görüyorsanız, bozulma ve fsck hakkında endişelenmeden önce aşağıdakileri deneyin.
$ Sudo umount /mnt/raid1/cra/257ad35ee0b12a714530c30dccf9210f
$ ls -alh /mnt/raid1/cra
257ad35ee0b12a714530c30dccf9210f klasörünü soru işaretleri yerine izinlere ve özniteliklere sahip olarak görmelisiniz. Öyleyse, mount komutunuz veya/etc/fstab dosyanız için diğer seçenekleri arayın. Değilse, belki de diğer cevapları okuma, yapabildiklerinizi yedekleme ve bir fsck çalıştırma zamanıdır.
İnsanlıktan mümkün olan en kısa sürede bir yedek alın, ancak herhangi bir potansiyel hasarı onarmaya çalışırken daha fazla karmaşa yaparsanız, orijinal daha az kırılmış durumuna geri dönebilirsiniz. Yedekledikten sonra, herhangi bir sorun olduğunu düşünüp düşünmediğini görmek için fsck'i çalıştırabilirsiniz.
Dosya adları sadece görüntülenemeyen karakterler içerebilir. Emacs DirEd ile dosya adlarını kontrol etmeye çalışın:
http://www.cs.utah.edu/dept/old/texinfo/emacs19/emacs_32.html
Bozuk bir dosya sistemine (reiserfs) sahip bir sunucumuz vardı ve dosya adı dışındaki tüm öznitelikler için soru işaretli dizin girişleri oluşturdu. Bizim durumumuzda, dosya adları etkilenmedi.
Ayrıca, boş alan yanlış rapor ediliyordu. du -sh /* Kullanarak yalnızca 30G'yi hesaplayabiliriz, ancak sürücünün kullanımda 200G'den fazla olduğu bildiriliyordu.
Dosya sistemi denetimini zorlamak için sunucuyu shutdown -rF now İle yeniden başlatmak işe yaramadı. Tek kullanıcı moduna geçip çalıştırmak zorunda kaldım:
fsck.reiserfs --rebuild-tree /dev/sda3
Bu neredeyse çalıştı. Birkaç geçişten sonra kilitlendi. İşletim sistemini yeniden yüklemek zorunda kaldım.
Yedeklerinizi koruyun!
Bunu autofs çalıştırırken de gördüm ancak autofs dizini bağlayamıyor. Bu yüzden neden dizini bağlayamadığını anlamak için autofs'i devre dışı bıraktım ve dizini manuel olarak bağlamaya çalıştım (bu da dizini silmeme izin verdi). Dizini manuel olarak bağlamayı denedim ve izin hatası olduğunu gördüm. Bunu düzelttikten sonra dizin tekrar normale döndü.
Sunucuda çalışan diğer işlemlere dikkat edin, örneğin rsync
[[email protected] upload]# ls -la
ls: cannot access .3bfb3dc5-cb55-435f-8e23-2afcab2c6873_image4993891600240007749.jpg.bV6VTV: No such file or directory
total 194496
drwxr-x--- 2 gx Apache 1382 Jan 11 10:36 .
drwxr-x--- 3 gx Apache 3 Jan 11 10:29 ..
-rw-r--r-- 1 gx Apache 94850 Dec 10 2015 37d355b9-210d-45df-8061-968ea5cb9f31_mob.jpg
...
-rw-r--r-- 1 gx Apache 10864 Jul 24 2015 3bfb23bf-8ff5-4603-aa57-9b23ca498e2c_internet.png
-rw-r--r-- 1 gx Apache 10864 Jul 24 2015 .3bfb23bf-8ff5-4603-aa57-9b23ca498e2c_internet.png.nHmIPk
-????????? ? ? ? ? ? .3bfb3dc5-cb65-435f-8e23-2agcab2c6873_image4993891600240007749.jpg.bV6VTV
rm, mv vb.
Bazen bir NFS sunucusu aşırı yüklendiğinde geçici bir hata olarak görüyorum.
OP RAID'i sordu, ancak birkaç cevap NFS'den bahsediyor ve aslında beni buraya getiren arama buydu.
Sadece farklı bir bakış açısı vermek için - bir dosyadaki (Ruby'de) bir liste dizinlerinden programlı olarak dizinler üretirken bunu yaşadım.
Tabii ki dosyadaki satır sonunda bir\n ile bir dize olarak geldi - ki bu iyi görünüyordu ve işe yaramış gibiydi. Ancak chomped yerine dizinleri oluşturmaya başladığımda her dizinden iki tane oluşturdu: /whatiwanted ve /whatiwanted?.