• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 602
  • Last Modified:

SBS Problem with NTFS flagging data drive 'dirty' and causing people to be unable to save there

Hi, on sporadic occasions (once in the last 4 weeks and 3 times in the week prior) our data drive flags as dirty and we then have problems saving data onto there (and i worry that we may  be losing data too). When a chkdsk /x is performed various error messages are raised and none are consistently present, sometimes problems with MFT, sometimes security descriptors.

The discs are 15k SAS used in RAID 10 on PERC 5i with a hot spare.

I had a similar problem a lot of years ago and it turned out to be extremely long path/name combinations so i exported a 'dir' command of the entire disk and used excel to display the total length of the path/title and sort them by this length. I renamed or deleted anything which was greater than 180 characters but in this case it has not helped.

Does anyone have any help they can share please?

Thanks

Wesley
0
Concept_Wes
Asked:
Concept_Wes
  • 7
  • 6
1 Solution
 
AustinDellManCommented:
Can you export the TTY log from the controller and post.

Sounds like corruption and you will most likely need to run CHKDSK /r from recovery console repeatedly until no errors are reported.  It is very important that you continually run until it comes back and reports no errors found.

Also, I would like to check the TTY log to ensure you don't have a punctured stripe.
0
 
Concept_WesAuthor Commented:
I am trying to extract the TTY log - is this from within OpenManage? If so, where should I find it please?

Thanks

Wesley
0
 
Concept_WesAuthor Commented:
I think I have found it now:

 lsi-1020.log


 TTY-00000000.log
0
Restore individual SQL databases with ease

Veeam Explorer for Microsoft SQL Server delivers an easy-to-use, wizard-driven interface for restoring your databases from a backup. No expert SQL background required. Web interface provides a complete view of all available SQL databases to simplify the recovery of lost database

 
AustinDellManCommented:
Per the TTY log, PD 5 is throwing unexpected sense keys:

10/20/11 15:52:14: EVT#5896415-10/20/11 15:52:14: 113=Unexpected sense: PD 05(e1/s5), CDB: 12 01 dc 01 1d 00, Sense: 70 00 05 00 00 00 00 28 00 00 00 00 24 00 00 00 00 00 00 12 01 0

10/20/11 15:52:20: DEV_REC:IllegalReq- CDB: 12 1 dc 1 1d 0

10/20/11 15:52:20: ILLEGAL REQ: pRdm(a0730600) Cmd=3, Sns=a0730640 DevId[5] Tgt 5

10/20/11 15:52:20:   info:       0, aslen=28, cmdSpecific[3]= 0 [2]= 0  [1]= 0 [0]= 0

10/20/11 15:52:20: asc=24, Ascq  0, Sks: 0, fp[0]= 0, fp[1]= 0

10/20/11 15:52:20: EVT#5896416-10/20/11 15:52:20: 113=Unexpected sense: PD 05(e1/s5), CDB: 12 01 dc 01 1d 00, Sense: 70 00 05 00 00 00 00 28 00 00 00 00 24 00 00 00 00 00 00 12 01 0


Was Physical Disc 5 recently replaced as it differs from the others:

T59: PD  Flags    State Type Size     SATA Vendor   Product         Rev  P C ID SAS Addr         Port

T59: --  -------- ----- ---- -------- ---- -------- --------------- ---- - - -- ---------------- ----

T59: 0   f0400005 00020 00   088bb939 0    SEAGATE  ST373455SS       S515 0 0 00 5000c50005892b05    0

T59: 1   f0400005 00020 00   088bb939 0    SEAGATE  ST373455SS       S515 0 0 01 5000c5000588e40d    1

T59: 2   f0400005 00020 00   11177327 0    FUJITSU  MAX3147RC        D207 0 0 02 500000e016d02292    2

T59: 3   f0400005 00020 00   11177327 0    FUJITSU  MAX3147RC        D207 0 0 03 500000e016cffe22    3

T59: 4   f0400005 00020 00   11177327 0    FUJITSU  MAX3147RC        D207 0 0 04 500000e016d05d12    4

T59: 5   f0400005 00020 00   111f839f 0    FUJITSU  MBA3147RC        0103 0 0 05 500000e1160d6da2    5

T59: 8   00400005 00020 0d   00000000 0    DP       BACKPLANE        1.05 0 0 08 5001c030bf90c700    9

T59: ff  00400005 00020 03   00000000 0                                   0 0 ff                0    0



The log shows that this drive is acting as your hotspare so I dont see that the unexpected sense key would be a problem unless the drive is built into the array.

No signs of Puncture but looks like the system was rebooted recently so no depth to the log.  

I would proceed as discussed before, with running CHKDSK /R repeatedly until no error are found.  Also, please generate another log and post for me.

www.support.dell.com/dset

This utility will run a log generater against the system so we can look at some other hardware.
0
 
Concept_WesAuthor Commented:
AustinDellMan, thanks so much for looking over these for me - the reboot was a power cut I have been told (I am a remote worker) and annoyingly I have view only access through the DRAC 5 though it should be full access I havent had time to check this so i can get to the chkdsk /r in the install mode just yet:(

I am just running a DEST report now and will upload this as soon as it finishes.

Thanks again

Wes
0
 
AustinDellManCommented:
Okay, good deal.  I will also look at hard drive firmware revisions to ensure there are not updates.
0
 
Concept_WesAuthor Commented:
AustinDellMan, unfortunately the file uploader does not allow the .hta viewer in the zip file - what is the best course of action from your view?

Thanks
0
 
AustinDellManCommented:
change the file extension on it and try again.
0
 
AustinDellManCommented:
You can email it to me at ben@austinpcdr.com if it is not over 50 MB
0
 
Concept_WesAuthor Commented:
That is sent by email (just over 1 MB)

Thanks

Wesley
0
 
AustinDellManCommented:
The one thing that stands out in the DSET is the fact that the RAID 5 is running a full cosistancy check.  At this point it is absolutely necessary to run CHKDSK /r post the completion of the resynching process.  You can check this via OMSA or running DSET again and looking at the storage section.

Make sure that you run CHKDSK /r repeatedly until it reports "No Errors Found"

0
 
AustinDellManCommented:
Also, noted that a memory dump exist that was created on 10-20-2011, you should run that thru the debugger and see what caused the dump to occur.
0
 
Concept_WesAuthor Commented:
Thanks so much for the help - I managed to move all data onto a temporary drive and delete the partition, then recreate using Computer Manager in Administrative tools, and moving data back - all seems to be well for now!

Can only assume that the partition created by Acronis was to blame?

Thanks

Wes
0

Featured Post

Configuration Guide and Best Practices

Read the guide to learn how to orchestrate Data ONTAP, create application-consistent backups and enable fast recovery from NetApp storage snapshots. Version 9.5 also contains performance and scalability enhancements to meet the needs of the largest enterprise environments.

  • 7
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now