[Boards: 3 / a / aco / adv / an / asp / b / bant / biz / c / can / cgl / ck / cm / co / cock / d / diy / e / fa / fap / fit / fitlit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mlpol / mo / mtv / mu / n / news / o / out / outsoc / p / po / pol / qa / qst / r / r9k / s / s4s / sci / soc / sp / spa / t / tg / toy / trash / trv / tv / u / v / vg / vint / vip / vp / vr / w / wg / wsg / wsr / x / y ] [Search | Free Show | Home]

Hello! Need help. I had an unmountable boot volume bsod a few

This is a blue board which means that it's for everybody (Safe For Work content only). If you see any adult content, please report it.

Thread replies: 30
Thread images: 2

File: pending sector.jpg (73KB, 653x215px) Image search: [Google]
pending sector.jpg
73KB, 653x215px
Hello!

Need help. I had an unmountable boot volume bsod a few weeks ago.

Managed to run chkdsk and it seemingly fixed it, but was still worried about my hd. Then it came back. Same story, but sometimes my computer hangs a little on boot.

Then I decided to check with crystal disk and I see this, "current pending sector count 200" error.

My drive is a 4-5 year old WD. It passes the long test in WDs lifeguard tool, sometimes it passes the short one, sometimes not with the error:

"SMART Offline Immediate Command Failure Self-Monitoring, Analysis, and Reporting Technology (SMART) Offline Immediate command failed. This may be due to a media error. It also may be due to a defective connection.
>>
File: pending 2.jpg (67KB, 654x215px) Image search: [Google]
pending 2.jpg
67KB, 654x215px
>>305542
Heres the upper part of the crystal disk list.

Does anyone know whats going on?
>>
You have two damaged sectors that should be swapped with the spares, but for some reason they're not. Maybe your trashy western disk didn't come with spare sectors, who cares. There may be more bad sectors that haven't been found out because you haven't tried writing to them, so if you want to know you could overwrite all your free space. Or not.
>>
>>305542
it's 4-5 years old? could be a good time to move everything to a new drive.
>>
>>305879

It is. And I have made backups, but is there anything I can do to save it?

A new disk is almost a new computer for me....
>>
stop playing around with the drive and clone it to a new one before you can't get anything off it. its failing and your constant fiddling with it is making it worst.
>>
>>305555
Disks don't swap sectors until the host overwrites them, and pending sectors appear after a read error, not a write error.

You knew that and were just pretending, right?
>>
>>305915

>is there anything I can do to save it?

Nothing bad is going on. This is literally nothing. I have a disk with over 350k bad sectors and 70k hours and I monitor it constantly to see if it's getting worse; it's not. It's been like this for a couple years and it's been pretty stable. Your disk is 100% fine and you have no reason to worry.

>>305920

>mad WD shill cucks on full damage control

No, fuck you. Real HDDs don't work like that.
>>
>>306082

What about the bsods I sometimes get on boot then?
>>
>>306082
They all do this, you complete and total spastic.

http://lmgtfy.com/?q=when+are+pending+sectors+remapped
>>
>>306088

A HDD will not produce a BSOD, you can even try to boot without a HDD at all and the stop error won't be a BSOD. If you have a BSOD it's either a critical hardware problem or some problem with your OS (e.g. if your HDD is damaged right where the OS is stored, it will trigger a BSOD at some point when loading the OS. This is not because of the damage to the disk itself, but because of the system files), a HDD/bad HDD/lack of HDD has nothing to do with it because it isn't a critical failure; computers can run properly without HDD, it's just that you won't be able to do much.

>>306125

>uses Google

No wonder you're a retard pal. I ain't even clicking that shit.
>>
>>306152

I see. Is there anything I can do to fix that? (damaged system files that is.)
>>
>>306170

If that was it, you could use the Windows disk to fix them, but you don't know for sure if it's that. Check the exact message you get in the BSOD to know what the problem is. Also the info doesn't mean that you have only 2 bad sectors, it means that you have only discovered two. There might be more and the damage could be big, but it also could be nothing significant. You also said that it sometimes passes the test and sometimes it doesn't, which shouldn't be like that if it was due to irrecoverable sectors; it's worth considering that the cable might be bad or something like that.
>>
>>306152
Well clearly you didn't google it, or you'd not be writing cretinous shit like that.

Imagine if the hard disk spontaneously decided it was going to silently transform 512 bytes of your database of banned users into 512 zeroes? It would be a total fucking disaster.

No hard disk remaps sectors until they're overwritten, because randomly altering data the computer has stored and expects to stay stored would be completely and utterly retarded.

Like you.
>>
>>306152
>A HDD will not produce a BSOD
Sure it will.

Trivially, if the sector the VMM wrote to the swapfile isn't the same when it reads it back in, that's memory corruption and blam, BSOD.
>>
>>306190

>transform 512 bytes of your database of banned users into 512 zeroes
>not understanding even the most basic things about the shit you're saying

512 bytes would be 4096 zeros retard. Stop talking about shit you clearly don't understand.

>because randomly altering data the computer

Are you retarded? That's totally not how it works.

>bad sector
>read it
>it works
>the HDD chipset copies the info to a spare sector and remaps it internally

Alternatively:

>bad sector
>read it
>too bad to even be read
>the HDD chipset remaps it internally, the info is lost anyway and your shit will be corrupted and your OS is fine with that

Also nice Reddit spacing faggot. Go back.
>>
>>306197
Most people understand "zero" to also mean a byte with the value of zero, you absolute twathandle.

>>too bad to even be read
>>the HDD chipset remaps it internally, the info is lost anyway and your shit will be corrupted and your OS is fine with that
Nope, you are 100% wrong, because you are a giant retard.

Disks never silently alter data, because that would be retarded like you. If it can't read the sector, it reports a read error, and continues to report a read error, until the data to be read is not there anymore because the OS has overwritten it. Silently removing the data and not telling anyone would be retarded, like you, so no storage device ever does this.

>nice Reddit spacing
Right back at ya.
>>
>>306200

>the OS has overwritten it

The OS can't overwrite over a bad sector...

>removing the data and not telling anyone

You aren't removing anything because there isn't anything there. The data is a logical abstraction over physical space; your HDD can move data physically while remapping sectors without telling your OS and nothing will happen because your OS only cares about the logical representation of it. On the other hand, if the sector is already too bad to be even read, the data is already corrupted no matter what you do (and your OS will realize it no matter what you do), so you remap that sector all the same.

>Right back at ya.
>comparing a coherent structure to a one-line-per-sentence-in-order-to-get-attention Reddit format
>>
>>306207
>The OS can't overwrite a bad sector
It absolutely can, that's the entire fucking point of there being a mapping of logical sectors to physical sectors.
>>
>>306207
>your OS will realize it no matter what you do
It won't if you remap the sector to one that doesn't have that data in without telling it, dumbass.

This is why devices return a read error when it's read, and don't remap the sector until it's overwritten.

FAT, NTFS and ext4 have no concept whatsoever of data verification, so if there's a badsector in the middle of a file, the only way they'll know is if the device produces a read error.
>>
>>306209

Then you aren't writing over the bad sector anymore. Wrong by definition.

>>306216

>It won't if you remap the sector to one that doesn't have that data in without telling it, dumbass

Yes, it will. There are multiple ways to verify data integrity in real time using all kind of things such as bit sums, the file headers, checksums and more.

>NTFS and ext4 have no concept whatsoever of data verification

You are dead wrong once again; probably twisting the info to fit your narrative. All modern file systems support all sorts of data integrity validation features, to provide an example, some support features as intensive as full physical journaling:

https://www.kernel.org/doc/Documentation/filesystems/ext4.txt

>the only way they'll know is if the device produces a read error

Your OS doesn't even know when an internal read error occurred. Neither it does know that you're remapping sectors because logically everything seems the same. This is the whole point of the HDD having a chipset that manges it: taking the load of certain tasks off the CPU and OS by creating an abstraction layer that takes care of the low level stuff. Also, since you keep bringing the same refuted shit over and over, allow me to repeat it (and I won't take you seriously anymore if you are unable to address it properly); you say that:

>find bad sector
>data isn't readable
>therefore can't remap it internally, because the file would be corrupted, since the swapped sector wouldn't have the correct data (it would be empty)

But conveniently ignore that if the sector is bad enough that it can't be read, then the data is already corrupted independently of if you swap or don't. You're arguing stupid shit that is illogical, have been proven wrong on several claims, are calling a lot of names, and your only evidence is 'lol google it'. It's time for you to bite a bullet pal.
>>
>>306200
>Silently removing the data and not telling anyone would be retarded

That's not how disks work though. To the system a HDD is pretty much a block box that the system asks "Please write this stream of data somewhere and add its positions to your file table." The rest does the controller of the disk, how it exactly internally works and for example which sectors the bytes are written to is of no interest for the system, it just connects to the controller and that one takes data and delivers it. Only the CONTROLLER knows where the data is physically stored, the system is just like "We need THIS file" and the controller then collects all pieces and delivers it. If the drive detects a broken sector it marks it as broken in its table and replaces it with a spare one so that the total numbers of sectors stays the same. Modern drives try to reallocate the data that was on the sector too by looking at read errors before it completely gets destroyed, but if it happens from moment to the next the data that was in that sector is lost. To the SYSTEM it is unintersting where exactly those sectors are physically, to it nothing has changed in fact, when next connnecting to the controller in a read or write command the controller simply delivers the same sector as still existing while internally using the replacement one, for the system nothing has changed, it can still write to sector X, but his one is now on a physically different section of the platter.
The LOGIC REPRESENTAION stays the same, what the Disk does internally is not the system's business!
>>
>>305915
well. if it was me: complete backup, low-level format, restore and if the drive is still giving you dead sectors, then it's faulty and you should donate it to someone you don't like.
>>
>>306228
>All modern file systems support all sorts of data integrity validation features
NO THEY FUCKING DON'T, and you can very easily test this by looking up the sector your file is at, zeroing it on the block device, and seeing if you get any error or notification whatsoever. You won't, because Ext4, FAT and NTFS do not validate their data against it changing once it's on the device.

If you can't be fucked to do this test, concede the point. It's really fucking simple, it'll take a minute at most for a clever person such as yourself to do, and it'll save you making an idiot of yourself again quoting stuff you fished out of Google but don't understand.

>some support features as intensive as full physical journaling:
That provides transactionality across power failure for metadata (and optionally data), and can't detect data silently changing after it's written. Try again.

>>306228
>Your OS doesn't even know when an internal read error occurred.
Yes it does, BECAUSE THE DEVICE TELLS IT. Read the fucking ATA standard. Unrecoverable read errors get sent to the host, because the device isn't in a position to determine what to do about it.

What do you think this RAID fast-fail even is, if drives can't report read errors?

>>306238
That's a really nice wall of text, but obviously we're talking about the logical sector not the physical one. How would it even be possible to "remap" a physical sector anyway? Elves?
>>
>>306238
>a block box that the system asks "Please write this stream of data somewhere and add its positions to your file table."
>the system is just like "We need THIS file" and the controller then collects all pieces and delivers it.
What you're describing here is an Object Store, which SATA drives emphatically are not. SATA drives can't do this, and no consumer OS can interface with object stores anyway.

The way it actually works is that the OS keeps track of files (using something called a "filesystem"), and the device provides an array of sectors, addressable by the OS using their Logical Block Address (earlier drives used what was effectively an LBA but with CHS addressing, and earlier drives still had no form of abstraction layer and didn't remap and left the OS to keep track of bad sectors) that the OS stores the files and "filesystem" on.

Hard disks don't have anything analogous to a "file table" they "add these positions to"; they have a list of badsectors, and that's it. The OS goes "get me block 1846372749263", and the drive looks down its badsector list, sees it isn't in it, uses a static mapping to translate it to a physical address, and goes and gets it. It doesn't know if the sector is part of a file, some metadata, or just some sector the OS is reading on a whim.

ATA devices are not object stores, and I have no idea where you got this idea. All they are are arrays of sectors, with no intelligence beyond the physical-sector/LBA-address abstraction.
>>
>>306562

What is a low level format? Does it delete everything on the drive?
>>
>>306603
It does, but it's not been a thing since 1985 and MFM drives. He's just using it as slang for "overwrite the drive with zeroes".
>>
>>306605

But doesnt that option delete everything as well?
>>
>>306607
Yes it does.
>>
>>306608

Darn then. That does not really help with my limited expertise.
Thread posts: 30
Thread images: 2


[Boards: 3 / a / aco / adv / an / asp / b / bant / biz / c / can / cgl / ck / cm / co / cock / d / diy / e / fa / fap / fit / fitlit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mlpol / mo / mtv / mu / n / news / o / out / outsoc / p / po / pol / qa / qst / r / r9k / s / s4s / sci / soc / sp / spa / t / tg / toy / trash / trv / tv / u / v / vg / vint / vip / vp / vr / w / wg / wsg / wsr / x / y] [Search | Top | Home]

I'm aware that Imgur.com will stop allowing adult images since 15th of May. I'm taking actions to backup as much data as possible.
Read more on this topic here - https://archived.moe/talk/thread/1694/


If you need a post removed click on it's [Report] button and follow the instruction.
DMCA Content Takedown via dmca.com
All images are hosted on imgur.com.
If you like this website please support us by donating with Bitcoins at 16mKtbZiwW52BLkibtCr8jUg2KVUMTxVQ5
All trademarks and copyrights on this page are owned by their respective parties.
Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.
This is a 4chan archive - all of the content originated from that site.
This means that RandomArchive shows their content, archived.
If you need information for a Poster - contact them.