Technology

58150 readers

5289 users here now

This is a most excellent place for technology news and articles.

Our Rules

Follow the lemmy.world rules.
Only tech related content.
Be excellent to each another!
Mod approved content bots can post up to 10 articles per day.
Threads asking for personal tech support may be deleted.
Politics threads may be removed.
No memes allowed as posts, OK to post as comments.
Only approved bots from the list below, to ask if your bot can be added please contact us.
Check for duplicates before posting, duplicates may be removed

Approved Bots

founded 1 year ago

MODERATORS

-5

Friendly reminder to never forcebly shutdown your PC (lemmy.world)

submitted 1 year ago by sourcepie@lemmy.world to c/technology@lemmy.world

29 comments fedilink hide all child comments

I just lost 44 GB of data that I downloaded in the past two hours. My PC started to get laggy and it got stuck so I just shut it down believing that all will be well since the data has already been written to disk..

you are viewing a single comment's thread
view the rest of the comments

[–] drspod@lemmy.ml 8 points 1 year ago (2 children)

What filesystem are you using? Filesystems should be crash consistent these days.

[–] AProfessional@lemmy.world 5 points 1 year ago (1 children)

A modern filesystem cannot make magic happen, if the data was in the process of being written it is still in memory and lost.

Only copy-on-write filesystems are safe here as they don’t overwrite old data. NTFS is not safe.

[–] drspod@lemmy.ml 3 points 1 year ago (1 children)

If 44GB had not been flushed to disk yet then that implies that OP has >44GB of RAM in use as page cache. SSD write caches are only around 2GB while HDD write caches are not more than about 512MB. I don't know how much RAM OP has but this seems unlikely to be the case.

I would bet on one of the following:

the transfer was still in progress when the system was halted
the transfer was not a network download but actually a copy from another locally mounted partition and the OS was still transferring data
the filesystem driver did write that 44GB to inodes but didn't link the inodes into the filesystem yet, in which case the filesystem's fsck tool should be able to recover data blocks that were already written
OP is using a filesystem which does not use either journaling or COW (eg. FAT32) in which case the data which was written but not linked into the filesystem is lost as orphaned inodes.

3 & 4 being the reason I was asking what filesystem OP is using.

Only copy-on-write filesystems are safe here as they don’t overwrite old data.

COW filesystems make no difference in this case since this was not data overwriting an existing file. They still have the same behavior with write caching in the OS and on the drive and still require a tool (eg. btrfs-check) to recover unlinked changes in the event of a crash.

NTFS is not safe.

NTFS is a journaling filesystem and is crash-consistent. That doesn't mean it can do "magic" if the data hasn't hit the disk, but it does mean that it won't corrupt the filesystem or lose data which was already written in the case of a crash.

[–] AProfessional@lemmy.world 1 points 1 year ago

I didn’t mean OPs case.

Journaling just means it knows what failed. Without CoW you will corrupt data.

[–] sourcepie@lemmy.world 2 points 1 year ago (1 children)

My filesystem was NTFS

[–] drspod@lemmy.ml 1 points 1 year ago* (last edited 1 year ago)

If you haven't tried it already, you could run chkdsk to see if the filesystem needs repairing. You can do it from the command-line^[1] or also through the drive properties > Tools > Check button.

[1] https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chkdsk?tabs=event-viewer

chkdsk
/f 	Fixes errors on the disk. The disk must be locked. If chkdsk cannot lock the drive, a message appears 
        that asks you if you want to check the drive the next time you restart the computer.