- Hálózatokról alaposan
- Xiaomi AX3600 WiFi 6 AIoT Router
- Sokat fogyaszt az AI, egyre több az adatközpont, kell az atomenergia
- Az iPadOS-re írt appokra is díjat vet ki az Apple
- Letartóztatták a bitcoin-Jézust
- ASUS routerek
- Asustor NAS
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- A pápa egyre jobban tart a romlott AI veszélyeitől
- Milyen program, ami...?
Új hozzászólás Aktív témák
-
batagy
őstag
Sziasztok!
Találkoztatok már olyan jelenséggel, hogyha hosszabb ideig sok kisméretű fájl kerül a vinyóra, akkor egy idő után belassul a vinyó?
Pl. sok FLAC letöltés, és Rar-ozott filmek letöltése. Aztán hiába törli az ember a Rar-okat, egy idő után érezni hogy lassan lehet a fájlrendszerben bármit csinálni.
Winről és NTFS-ről beszélek.
Régebben is észrevettem már ezt, amikor még XP-t használtam, és kétféle megoldást tudtam rá:
- ha a rendszerpartíciót újraformáztam (teljes formázással) és a rendszert újratelepítettem. (C:\)
- vagy akkor is visszagyorsult a vinyó, ha csak átneveztem a D:\ meghajtó betűjelet az XP-ben.
Én akkor azt a konklúziót hoztam magamban, hogy a rendszervinyón valahogy a fájlrendszer vagy MFT betelik vagy hasonló.Most ugyanezt Win7-tel is tapasztalom. A múltkorában, amikor a Win7-et telepítettem, a telepítőben akkor is újraformázást nyomtam a C:\-re. Azonban a Win7 már nem csinált teljes formázást, hanem csak gyorsformázást. Utána is azóta is úgy érzem, a vinyó még mindig lassú, hiába lett újraformázva a C: gyorsformázással.
Ez normális jelenség?
Hogyan lehet megoldani?Na de amikor ki akarok lyukadni, ez:
szóval gondoltam hogy teljes formázás vagy low level formázás segít, de azt olvasom hogy a modern vinyókon nem is szabad low level formázást végrehajtani. Igaz ez?Samsung HD322HJ a szóban forgó vinyó.
Kösz!
-
batagy
őstag
Sziasztok!
Nekem nincs (már) problémám, csak egy rövid siker történetet szeretnék megírni, hátha valakinek segít, ha ugyanilyen bajba kerül.
Seagate 2.5"-es 500 GB-os ST500LM012 vinyó. 1 db NTFS partíció, tele adattal. Innostor IS621 chipes USB3.0-as rackben használtam. Az előlapi USB3 kivezetésem meglehetősen instabil.
Valószínűleg a rackben is volt valami kontakthiba.Az instabil USB3 csatlakozás miatt , miközben adatokat olvastam Win 8.1 alatt, egyik alkalommal valahogy úgy csatlakozott le, hogy az MFT korrupt lett. Utána Windows nem ismerte már fel a fájlrendszert, és Linux alatt sem lehetett felmountolni a vinyót.
Abban biztos voltam, hogy nem vinyó hiba, és nem szektor hiba, hanem csak valami fájlrendszer korrupcióról van szó, így megőriztem a hidegvéremet.
1)
Először vennem kellett egy nagyobb vinyót, hogy a HDD image-et le tudjam klónozni a biztonság miatt. Seagate ST2000LM003, 2 TB-os 2.5"-es megérkezett.2)
Mindenek előtt a HDD klónozása a fontos, mielőtt bármi mást csinálunk.
Legjobb erre:
Linux alatt TestDisk.
Advanced -> Image Creation.
Ez csinál egy image.dd fájlt 500 GB méretben megadott cél helyen (esetemben a 2 TB vinyón).Megjegyzés:
Asmedia USB3 chipek Linux 3.17 kernel előtt (nálam 3.16 kernel fut, OpenSUSE 13.2) hibáznak, legalábbis van ismétlődő egy dmesg hibaüzenet. Ezért Asmedia chipes USB3-at nem célszerű használni a másolás során, legalábbis, ha a kernel 3.17-nél régebbi. Nálam a másolás során a 2TB-s vinyó Marwell chipes eSATA-n volt csatlakoztatva, a sérült 500 GB-os vinyó pedig egy külső Innostor IS621 chipes USB3 adapteren.Klónozás után próbálkozások:
3)
Linux alatt TestDisk.
Analyse
Az 1 NTFS partíciót kijelezte, de fájlokat semmit sem tudott megjeleníteni.
Backup -> Enter -> Write
Ez elvileg az MBR-t helyreállítja. Nekem nem oldotta meg.4)
Linux alatt TestDisk.
Advanced -> Boot -> Repair MFT
Sajnos nem tudott lefutni, nem javított ki semmit. TestDisk hibaüzenet:
MFT and MFT mirror are bad. Failed to repair them.5)
Utána nem volt mit tenni, Windows alatt chkdsk próba (mindeközben a sérült vinyó végig IS621-es USB3-on hátsó portban)
Felfedeztem egy jó kis ingyenes GUI programot a chkdsk-hoz:
CheckDiskGUIFix és Repair-t választottam. Durván 2 óra alatt végzett. Valszeg csak a Fix önmagában is elég lett volna, mert a Repair a szektor hibákra való, az meg nincs.
Chkdisk log (a mappaneveket kitöröltem, mert nem releváns):Started on : 2016/05/16 09:00:36
The type of the file system is NTFS.
Volume label is Seagate-27.
Stage 1: Examining basic file system structure ...
Fixing incorrect information in file record segment 5.
Fixing incorrect information in file record segment 5.
Deleting corrupt attribute record (128, "")
from file record segment 5.
Fixing incorrect information in file record segment 6.
Fixing incorrect information in file record segment 6.
Fixing incorrect information in file record segment 7.
Fixing incorrect information in file record segment 7.
29312 file records processed.
File verification completed.
232 large file records processed.
0 bad file records processed.
Fixing flags for file record segment 5.
Correcting file name errors in system file record segment 5.
Correcting file name errors in system file record segment 6.
Correcting file name errors in system file record segment 7.
Stage 2: Examining file name linkage ...
Fixing incorrect information in file record segment 5.
Deleting index entry $AttrDef in index $I30 of file 6.
Deleting index entry $BadClus in index $I30 of file 6.
Deleting index entry $Bitmap in index $I30 of file 6.
Deleting index entry $Boot in index $I30 of file 6.
Deleting index entry $Extend in index $I30 of file 6.
Deleting index entry $LogFile in index $I30 of file 6.
Deleting index entry $MFT in index $I30 of file 6.
Deleting index entry $MFTMirr in index $I30 of file 6.
Deleting index entry $RECYCLE.BIN in index $I30 of file 6.
Deleting index entry $Secure in index $I30 of file 6.
Deleting index entry $UpCase in index $I30 of file 6.
Deleting index entry $Volume in index $I30 of file 6.
30766 index entries processed.
Index verification completed.
CHKDSK is creating new root directory.
CHKDSK is scanning unindexed files for reconnect to their original directory.
Recovering orphaned file $MFT (0) into directory file 5.
Recovering orphaned file $MFTMirr (1) into directory file 5.
Recovering orphaned file $LogFile (2) into directory file 5.
Recovering orphaned file $Volume (3) into directory file 5.
Recovering orphaned file $AttrDef (4) into directory file 5.
Fixing incorrect information in file record segment 5.
Recovering orphaned file . (5) into directory file 5.
Recovering orphaned file $Bitmap (6) into directory file 5.
Recovering orphaned file $Boot (7) into directory file 5.
Recovering orphaned file $BadClus (8) into directory file 5.
Recovering orphaned file $Secure (9) into directory file 5.
Skipping further messages about recovering orphans.
38 unindexed files scanned.
0 unindexed files recovered.
Stage 3: Examining security descriptors ...
Cleaning up 9 unused index entries from index $SII of file 9.
Cleaning up 9 unused index entries from index $SDH of file 9.
Cleaning up 9 unused security descriptors.
Security descriptor verification completed.
729 data files processed.
CHKDSK is verifying Usn Journal...
Usn Journal verification completed.
Stage 4: Looking for bad clusters in user file data ...
29296 files processed.
File data verification completed.
Stage 5: Looking for bad, free clusters ...
1641719 free clusters processed.
Free space verification is complete.
Correcting errors in the Master File Table (MFT) mirror.
Correcting errors in the Boot File.
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.
No further action is required.
488385535 KB total disk space.
481700128 KB in 28323 files.
7332 KB in 730 indexes.
0 KB in bad sectors.
126107 KB in use by the system.
65536 KB occupied by the log file.
6551968 KB available on disk.
4096 bytes in each allocation unit.
122096383 total allocation units on disk.
1637992 allocation units available on disk.
Checkdisk of F: (Fix and recovery mode) started !
Ended on : 2016/05/16 10:46:48
Time elapsed : 6372 seconds6)
Chkdsk javítás után a Windows továbbra sem ismerte fel a fájlrendszert, azonban a Linux innentől már probléma nélkül felismerte!Így Linux alatt TestDisk-kel lemásoltam az összes fájlt a 2 TB-os vinyóra. Egyetlen egy fájl sem sérült meg.
Azaz csak az MFT-ben volt sérülés.Megfigyeltem, hogy a TestDisk a másolás közben szerencsére megtartja a fájlok és mappák módosítási idejét. Néhány másoló programban idegesítő, ha a mappák létrehozási ideje frissül. TestDisk az jól kezeli.
7)
Innentől megvan minden. A sérült vinyón érdemes az NTFS-t törölni, pl. gparted-del. Én EXT4-re formáztam, majd azt is töröltem, és vissza NTFS-re. Most már csak a fájlokat kell megint visszamásolni az eredeti vinyóra.8)
Csak kiegészítő infó:
image.dd fájlt Windows-ban fel lehet mountolni az igyenes OSFMount programmal! Ez persze nem oldja meg magát a korrupciót, hiszen az az image-ben benne van, de esetleg utána használni lehet más helyreállító programból ha az nem kezeli a dd image-et.9)
Csak kiegészítő infó:
Active@ Partition Recovery nevű Windows-os programmal (nem ingyenes) is próbálkoztam az elején, de végül nem használtam. Amúgy elég jónak tűnik. A sérült vinyón látta az összes fájlt és a mapparendszert! Kiválaszthattam volna, hogy a fájlokat és a mapparendszert mentse ki a cél vinyóra, de ez leformázza a célvinyót, ezért nem használtam ezt, mivel a a 2TB-s vinyón már rajta volt az image mentés. Másik megoldás, ha a programban direktben megnyitjuk a már kimentett image.dd fájlt is (mert ilyet is tud!), és a fájlok kimentése célvinyójának magát a sérült vinyót adjuk meg. Olyankor azt a sérült vinyót úgyis újraformázná. Végül ezt én nem használtam, mert ugye a chkdsk után TestDisk-kel le tudtam mindent menteni. De amúgy említésre méltó program.Konklúzió:
- Előlapi USB3-as kivezetésre figyelni. Én most már lehúztam az alaplapról és nem használom, túl kockázatos. Adatkapcsolati instabilitás okozza a gondot.
- Mielőtt bármiféle adathelyre állítást próbál az ember, a vinyó image-et érdemes lementeni. Legjobb erre , Linux alatt Testdisk, image.dd-be.
- Utána lehet próbálkozni különféle helyreállításokkal. Ha nincs szektorhiba, valszeg elég a chkdsk Fix.[ Szerkesztve ]
-
#44404
batagy
őstag
King Unique
#44402
batagy
őstag
válasz
King Unique
#44402
üzenetére
EXT3 vs NTFS kérdésben sokat keresgéltem neten, hogy érdemes-e EXT3 vagy EXT4 fájlrendszert használni média tárolásra, ha a Windows-on is használjuk. Mert nálam is pl. a NAS és a médialejátszó is kezeli az EXT3-at.
De aztán arra jutottam, hogy az NTFS jobb, ugyanis a Linuxban az NTFS kezelés nagyon stabil, ugyanakkor Windows-ban az EXT3/EXT4 kezelés meglehetősen instabil és hiányos még mind a mai napig.
Az EXT2IFS journal-t nem kezel, így megbízhatatlan.
A Paragon ExtFS-t ahogy láttam sokan szidták sokféle fórumokon. Nekem tapasztalatom nincs vele.Ext2FSD: Ez se megy PlugAnd Play, hanem egy tool-t kell hozzá használni ha az ember fel akar mountolni egy partíciót. Nem tudom mennyire megbízható.
Általánosságban, szerintem Windows-ból nem érdemes Linux fájlrendszert kezelni. Főleg írni rá.
[ Szerkesztve ]
-
#44406
batagy
őstag
King Unique
#44405
batagy
őstag
válasz
King Unique
#44405
üzenetére
Szerbusz!
Asmedia chippel kapcsolatban, megnéztem és reprodukáltam.
Ezt az USB3 adaptert régebben a gagyi kékszínű rackből szereltem ki.
HW: ASM1053
VID/PID: 174C/5136
FW: 110922110000 (eléggé régi)OpenSUSE 13.2, kernel 3.16.7:
sesame:~ # uname -r
3.16.7-35-desktop
sesame:~ #Hátsó USB3 portba dugva, alapból nincs semmi hiba, de amint olvasok róla, vagy írok rá, teledobálja a dmesg-et nekem (az utolsó 6 sorban lévő xhci_drop_endpoint hibaüzenet ismétlődik. Az eleje a sima felcsatolási üzenet, ez nem ismétlődik):
[May18 20:59] usb 4-2: new SuperSpeed USB device number 2 using xhci_hcd
[ +0.011881] usb 4-2: New USB device found, idVendor=174c, idProduct=5136
[ +0.000012] usb 4-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ +0.000003] usb 4-2: Product: AS2105
[ +0.000002] usb 4-2: Manufacturer: ASMedia
[ +0.000012] usb 4-2: SerialNumber: 00000000000000000000
[ +0.000563] usb-storage 4-2:1.0: USB Mass Storage device detected
[ +0.000848] scsi9 : usb-storage 4-2:1.0
[ +1.003754] scsi 9:0:0:0: Direct-Access ASMT 2105 0 PQ: 0 ANSI: 6
[ +0.000252] sd 9:0:0:0: Attached scsi generic sg4 type 0
[ +0.597018] sd 9:0:0:0: [sdd] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[ +0.000378] sd 9:0:0:0: [sdd] Write Protect is off
[ +0.000004] sd 9:0:0:0: [sdd] Mode Sense: 43 00 00 00
[ +0.000354] sd 9:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ +0.011574] sdd: sdd1
[ +0.001313] sd 9:0:0:0: [sdd] Attached SCSI disk
[May18 21:01] usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd
[ +0.011217] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801e5450640
[ +0.000004] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801e5450688
[ +1.145709] usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd
[ +0.011184] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801e5450640
[ +0.000004] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801e5450688Mikor keresgéltem ezt találtam , itt az oldal alján írták hogy ASM1051-es chip okozza, és hogy kernel 3.17-rc5-ben van
javítvaegy workaround.Lehetséges hogy az újabb 1153 és/vagy újabb ASMedia firmware-ekben ez már javítva van.
A diskpart részre külön válaszolok majd, mert nagyon jó hogy leírtad, majdnem szétszívattam magamat.
[ Szerkesztve ]
-
#44407
batagy
őstag
King Unique
#44405
batagy
őstag
válasz
King Unique
#44405
üzenetére
Na hali, megpróbálok válaszolni a Win-es mentési kérdésekre.
Hogy a Windows lemezkezelő mit mutatott a korrupt partícióra, azt sajnos akkor nem néztem meg. Elsősorban a Linuxból történő helyreállításra fókuszáltam.
A chkdsk javítás előtt, az biztos, hogy a Win-ben betűjelet kapott a meghajtó. Az Intéző a meghajtón lévő szabad/foglalt helyet már nem tudta megjeleníteni. Nem vagyok benne biztos, hogy RAW partíció volt-e. Viszont, a chkdks látta!
Linux alatt csak az NTFS partícionálás látszódott, de nem lehetett felmountolni és a fájlrendszer sem látszódott.A chkdsk javítás után, a Windows már felismerte hogy NTFS, és az Intéző a szabad/foglalt helyet is megjelenítette. Azonban, az Intéző állandóan homokórázott és belassította az USB kapcsolatokat.
A Linux ekkor már probléma nélkül látta a fájlokat.Viszont!
Nagyon örülök neki hogy leírtad a kommentjeidet, ugyanis mióta újrapartíconáltam a vinyót, azóta még a Windows-on nem néztem meg, szerencsére még a fájlokat sem kezdtem el rá visszamásolni. Most hogy rádugtam a Windows-ra (a már chkdsk-val javított, majd Linux alól újrapartícionált) vinyót, kiderült, hogy még mindig nem jó. A Windows továbbra is gondot észlelt, ugyanúgy mint a chkdsk javítás után. Az Intéző állandóan homokórázott és belassította az USB kapcsolatokat.
Megnéztem a lemezkezelő-ben, és RAW partíció van! Pedig azóta már egyszer EXT4-re, majd NFTS-re lett formázva Gparted-ből.Szóval fogtam diskpart leírásodat és nyomtam egy clean-t!
diskpart
list disk
select disk 7
list disk
clean
exitEz rakta most rendbe!!! A diskpart clean után a Win Lemezkezelőből MBR-re inicializáltam, majd létrehoztam az NTFS partíciót, és azóta korrektnek tűnik! Már nem homokórázik az Intéző és nem lassul be az USB.
Mindenesetre, az biztos hogy a chkdsk javítás után, majd Linuxból történő EXT4-re majd NTFS-re formázás után a vinyó még hibás maradt! Csak a diskpart clean rakta helyre.
Érdekes, ahogy olvasom a diskpart clean elvileg az MBR-t törli. Szóval lehetséges, hogy az MBR-rel volt az eredeti problémám, csak esetleg a TestDisk-kel nem azt generáltam újra! Erre tippelek.
(Legalább kipróbáltam, hogy a Win8.1 is jó szektorhatárokon (2k aligned) hozza létre a partíciókat. Azelőtt mindig gparted-ből formáztam. A Gparted amúgy a lemez végéig hozza létre mindig az MBR-es partíciókat, míg a Windows a lemez végén mindig hagy egy kis Unallocated helyet. Állítólag ez a GPT mentés miatt van. Mindegy ez most nem lényeg.)
A PhotoRec programot Linux alól én is próbáltam, és működött is, de a fájlokat ömlesztve és generált fájlnévvel mentette le, szóval nem őrizte meg a mappastruktúrát. Valamikor persze ez is több mint a semmi.
Azt bánom, hogy Linux alól a "ntfsfix /dev/sdc1" parancsot nem próbáltam ki. Bár még lehetne, ha a kimentett image.dd-t felmountolnám... Sőt az MBR regenerálást is ki lehetne próbálni ha az image.dd-t fel tudnám mountolni?
-
batagy
őstag
Átolvastam én is a leírt problémádat.
King-hez hasonlóan számomra is úgy tűnik, hogy vagy Win10-ben, vagy a rack firmware-ben van egy kis inkompatibilitási probléma, amely WD vinyóval jön ki írás közben.Jmicron JMS566 vezérlőhöz van elérhető firmware (nálam
)
00.01.01.04
00.01.01.06A Sharkoon oldalról letölthető firmware nem tudom hanyas verzió, de a fájl dátuma 2014.01.09, ami viszonylag régi.
A továbbiakat a 2.5" rack topikban lenne érdemes megvitatni, ezzel kapcsolatban.
Az usbdev oldaláról töltsd le légyszíves ezt a fájlt:
JMicron 2033x M.P. Tool v1.16.14.1
Ez kiírja a firmware verzióját, ha van türelmed, egy screenshotot szívesen fogadnánk a másik topikban.
De egyelőre ne csinálj rajta semmilyen frissítést további javaslatig!! -
batagy
őstag
Sziasztok!
Nagyon furcsa jelenséggel találkoztam.
USB rackben lévő Seagate ST2000LM003 (2TB-os) vinyón történik ez.
Fájlok/mappák összméretét csekkoltam és másoltam át másik vinyóra, miközben a cél vinyón betelt a hely. De nem értettem hogyan telt be, mert az általam kiválasztott forrás mappák össz mérete nem érte el azt.Miután ellenőriztem, kiderült, bizonyos fájlokat a Windows Intéző nem lát, ha egy mappa szinten nézem. Ha lejjebb megyek egy szintet, egészen más, sokkal több fájl látszódik.
Példa:
"Mokus" nevű mappa 309 GB méretűnek látszik, benne 15102 fájl. [kép1]Ha egy szinttel lejjebb megyek, és a tartalmát nézem ugyanígy, az 1.36 TB, összesen 61414 fájl. [kép2]
De még ez sem az igaz. WinDirStat programmal összesen 1.8 TB-ról van szó, 77565 fájl. [kép3]
Nos, hogy lehet hogy a Win Intéző nem mutatja? Hogyan lehet troubleshoot-olni, hogy pontosan melyik fájlok nem látszódnak és miért?
Mivel nagyon sok fájlról van szó, nem tudom kézzel ellenőrizni se így. Kellene valami módszer.Köszönet!
[ Szerkesztve ]
-
#50651
batagy
őstag
King Unique
#50648
batagy
őstag
válasz
King Unique
#50648
üzenetére
Köszönöm!
A rejtett fájlok megjelenítése nálam mindig is be van kapcsolva, nem ezzel függ össze a probléma.
Szövevényes mapparendszer sincs.Valamilyen indexelési gond lehet. A chkdsk valamit talál, amit pontosan nem tudok értelmezni, és a fix lefut. De utána is fennáll a probléma, végül nem tudja kijavítani.
A meghajtó szinten láttam hogy tele van a vinyó, de nem minden mappa szinten ellenőriztem. Csak bizonyos könyvtárakat, amit éppen másoltam, csak azokat. Nem merült fel, hogy az Intéző hibásan mutatja. Pont ennek kellene helyesen mutatni, nem 3rd party tool-oknak, na mindegy.
Máshol sosem találkoztam eddig ilyen problémával, csak ezen az egy helyen.
Végül is gondot nem okoz most már. Annyi, hogy mielőtt átmásolgatom, nem az Intézőből, hanem WinDirStat-ból fogom a mappa méretet ellenőrizni. A cél vinyón már helyes az adatméret.
[ Szerkesztve ]
)Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest