Jump to content

files 'missing'


jeffp

Recommended Posts

/mnt/user/ = All shares & files

/mnt/user0/ = All shares & files EXCEPT those on the cache.

Unless the OP has user and user0 mixed up, doesn't explain what he's describing

 

Would be wise to post the full diagnostics if the description as described in the OP is correct

Link to comment

/mnt/user/ = All shares & files

/mnt/user0/ = All shares & files EXCEPT those on the cache.

Unless the OP has user and user0 mixed up, doesn't explain what he's describing

 

Would be wise to post the full diagnostics if the description as described in the OP is correct

 

Yeah, I assumed he'd got it mixed up.

Link to comment

That I knew about /user and /user0. That is not the problem.

 

With no files added, and no changes, the SHARE shows no files.

 

The looking at /user and /user0 were to verify that my files were still there. Shouldn't the share show files regardless of which /user directory it is in?

 

Again - the look at the 2 /user directories was to look for the files. It is the share that is not showing ANY files.

Link to comment

no problems noted in Squid's plugin other than cache drive not happy.

 

System is in a parity check, so I'll wait until it is done to run any other diags that you link me to.

And so sorry that my fingers are stuck with not adding the e. It's what my fingers are used to.

 

 

Link to comment

Thank you Squid.

 

If it is the cache, I would guess that I could stop parity, turn off cache (nothing critical on it right now), then re-run parity.

Nothing dealing with the cache drive is ever going to affect a parity check.  Rather than be hasty, just post the diagnostics with parity running and people here can address the problems you're having
Link to comment

And to make everyone happy I'll edit my posts to add the e.

 

For the record, it didn't particularly upset me, I'm guessing if you're used to typing usr you're a linux user, trul was just trying to be helpful and stop you from running into issues down the road.

Link to comment

And to make everyone happy I'll edit my posts to add the e.

 

For the record, it didn't particularly upset me, I'm guessing if you're used to typing usr you're a linux user, trul was just trying to be helpful and stop you from running into issues down the road.

I actually rather liked it.  Kept CHBMB, and trurl on their toes since it was obviously a typo rather than a misunderstanding on your part  8)
Link to comment

And to make everyone happy I'll edit my posts to add the e.

 

For the record, it didn't particularly upset me, I'm guessing if you're used to typing usr you're a linux user, trul was just trying to be helpful and stop you from running into issues down the road.

I actually rather liked it.  Kept CHBMB, and trurl on their toes since it was obviously a typo rather than a misunderstanding on your part  8)

It was not "obviously" a typo, since it was consistently wrong as I mentioned.

 

Now that it has been fixed in the OPs this digression is pointless. ;D

Link to comment

Its the cache drive.

 

Started out here:

Nov  5 00:03:21 Tower kernel: ata5.00: exception Emask 0x0 SAct 0xc SErr 0x0 action 0x6 frozen
Nov  5 00:03:21 Tower kernel: ata5.00: failed command: WRITE FPDMA QUEUED
Nov  5 00:03:21 Tower kernel: ata5.00: cmd 61/00:10:78:46:fa/02:00:04:00:00/40 tag 2 ncq 262144 out
Nov  5 00:03:21 Tower kernel:         res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  5 00:03:21 Tower kernel: ata5.00: status: { DRDY }
Nov  5 00:03:21 Tower kernel: ata5.00: failed command: WRITE FPDMA QUEUED
Nov  5 00:03:21 Tower kernel: ata5.00: cmd 61/00:18:78:48:fa/02:00:04:00:00/40 tag 3 ncq 262144 out
Nov  5 00:03:21 Tower kernel:         res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov  5 00:03:21 Tower kernel: ata5.00: status: { DRDY }
Nov  5 00:03:21 Tower kernel: ata5: hard resetting link
Nov  5 00:03:31 Tower kernel: ata5: softreset failed (device not ready)
Nov  5 00:03:31 Tower kernel: ata5: hard resetting link
Nov  5 00:03:41 Tower kernel: ata5: softreset failed (device not ready)
Nov  5 00:03:41 Tower kernel: ata5: hard resetting link
Nov  5 00:03:52 Tower kernel: ata5: link is slow to respond, please be patient (ready=0)
Nov  5 00:04:16 Tower kernel: ata5: softreset failed (device not ready)
Nov  5 00:04:16 Tower kernel: ata5: limiting SATA link speed to 3.0 Gbps
Nov  5 00:04:16 Tower kernel: ata5: hard resetting link
Nov  5 00:04:22 Tower kernel: ata5: softreset failed (device not ready)

Which implies a sata and/or power connection to the drive, but ultimately the driver just plain gave up and dropped the drive

Nov  5 00:04:22 Tower kernel: ata5: reset failed, giving up
Nov  5 00:04:22 Tower kernel: ata5.00: disabled
Nov  5 00:04:22 Tower kernel: ata5: EH complete

 

And then it more or less went down hill from there...

 

Since the cache drive is very intimate with the user system (but not user0), any time it drops unexpectedly will mess up user shares

 

You're going to have to at least check and reseat all connections to the drive at both ends.

Link to comment

would it be better to

 

wait for parity to end then power down and check connection?

 

or

 

stop parity check, disable cache, run parity, then power down to reset?

 

Wonder what could have killed the cache, as the system hasn't been touched.

Link to comment

would it be better to

 

wait for parity to end then power down and check connection?

 

or

 

stop parity check, disable cache, run parity, then power down to reset?

 

Wonder what could have killed the cache, as the system hasn't been touched.

The cache drive isn't involved in parity check operations, so doesn't particularly matter on that score when you do it.  Its really a question of

 

- The extra time involved in restarting the parity check

- How soon you need the apps (docker) to be back running properly again.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...