Don't fall for the "never defrag an SSD" meme! Files fragment all the same as on an hdd, slowing down your reads and filling up your MFT (master file table) with the addresses of all those little fragments.>but SSD wear!SSDs last much longer than you thought, the official numbers are for the guarantee only (just like a car with a 3 year 50.000 mile guarantee won't explode after 3 years or 50.000 miles).>but still SSD wear!It only writes a few gigs the first time, after that there are barely any fragmented files so virtually no writes for the subsequent defrags.>but it's not necessary because SSDs are good at random read!They are much better at sequential read.>I don't want to do it, because Anand Tech Tips and LinusTech told me not to, I believe them and I'm scared!Once you reach maximum fragmentation you literally can't write anymore even if the disk is half empty.Come on Anon, looking at your freshly maintained drive is a fantastic, clean feeling. Write down how long it lasted (probably like 37 seconds) and how much data was written (for me 7GB for the OS disk after 2 years of use)
>>108750486isn't that what TRIM is for?
>>108750486>SCHIZO BABBLEProve there is a difference. You can't.
I'll stick with FFS and OpenBSDhttps://marc.info/?l=openbsd-misc&m=144738462109908&w=2
>>108750486Yes they do , that's why TRIM exists. and that's why by default most operating systems do it in intervals.
>>108750528enjoy your cucked software then
>>108750535What does cucked software mean
>>108750537
>>108750486>meaninglessly write on your SSD for increased performance!sure bro. going to decrease my ssd's life span for no reason now.
>>108750517https://www.overclock.net/threads/yes-file-system-fragmentation-does-affect-ssd-read-speed.1538878/
>>108750544This is philosophical nonsense. The OpenBSD source code is free. I can download it from SVN and build it using clang. I can cut out 80% of the source tree by removing the amdgpu driver (https://news.ycombinator.com/item?id=44830332 )That leaves me with the lightest and most secure OS that can run Firefox on Earth.Next I will work on gutting firefox in a similar fashion, goal being 10 million LOC or less.
>https://www.kernel.org/doc/html/next/process/stable-api-nonsense.html>leechFunny how GPL niggers think they get to call the people who release their works under the BSD3CL "Leaches", I see why now everyone fucking hates Linux Foundation with how you spit on people who license under BSD3CL, fucking arrogant faggots
>>108750486I am a filesystem engineer and it turns out, the ssd wear can be reduced by defragmentation. See, an ssd doesn't read/write single bits sequentially, it does everything in chunks. If your files are spread across multiple chunks, any access is multiplied. Often accessed files (the important ones) therefore can wear out the ssd much faster if fragmented.
>>108750558GNU advocates fight even with each other. They are lawyers at heart, not programmers.
On Windows at least you should run TRIM as infrequently as possible as it wipes your cache for the OS and makes everything load slower.
>>108750571I really wish we could reconcile things (BSD/Linux community, with regard to GPL vs BSD licensing)But both sides do use language like "leech" or "contamination", try introducing code to OpenBSD not under ISC for example you'll get bitched at (which you can't get mad about, it's theos project under his leadership at the end of the day)
This reminds me of the current BSD situation...https://lists.freedesktop.org/archives/dri-devel/2016-December/126516.html
>>108750486How do I do that on linux?
I checked the defragment drive menu and it says google "optimizes" it once a week by defaultso thats a thing
https://lists.freedesktop.org/archives/dri-devel/2016-December/126798.htmlEven if the code is shit can you imagine the herculean fucking effort of those AMD engineers to write 100,000+ lines of HAL code only to give it away to Linux for free and then the kernel developers wipe your ass with it?I can also understand why closed source has animosity with open source, I get it
>>108750597e4defrag if you use ext4 file systemit's probably unnecessary, linux is much better at not fragmenting your files than windows could ever hope to be
>>108750544>Engine—all made possibly my Cuck License cuckery.>made possibly my>emdasha jeet made this
>>108750564>Often accessed files (the important ones) therefore can wear out the ssd much faster if fragmented.But it's only wear if it is writing. Reading doesn't wear the drive at all.But you're otherwise right. In order to write to flash memory you have to wipe the blocks you're writing to first, which means if it's a highly fragmented write you'll be wiping and rewriting more blocks than if it were contiguous.But this is also part of what TRIM is supposed to be doing.
>>108750834Reading does induce wear, but yes, it's a couple of orders of magnitude weaker. But often accessed files are not necessarily only read. Systems often change or rewrite files during operation
>think of the billion dollar companies goyAGPL is the way. Whiny faggots ITT never produced anything worth stealing.
>>108750517made this pic like 16 years ago. Note how one part of the drive has significantly higher performance. It's the part with the contiguous empty space. Simply put, the drive works faster if it has to write to empty space, because it only has to do a write cycle, not a read-modify-write cycle.>but muh trim and firmwarestill works on modern drives, test it for yourself.>>108750834>But it's only wear if it is writing. Reading doesn't wear the drive at all.NTA but writing to fragmented space can add significant wear because when you write, for example, 50k as 50x 1k chunks to a heavily fragmented space you have to rewrite 50 entire full SSD cells which may be as large as 512k each. But when you write to consolidated free space you'd only have to write to one single 512k cell because the 50k you are writing all fits in one. Obviously this is an extreme example but when we have frequently modified user configs for example, it can happen.
>>108750932>NTA but writing to fragmented space can add significant wear because when you write, for example, 50k as 50x 1k chunks to a heavily fragmented space you have to rewrite 50 entire full SSD cells which may be as large as 512k each. But when you write to consolidated free space you'd only have to write to one single 512k cell because the 50k you are writing all fits in one.Yes, that is what I said.
>>108750597# systemctl enable --now fstrim.timer
>>108750486bitch I don't even defrag my hdd, it does more harm than good
>>108750628You are so fucking stupid
>>108751291What harm does it do to HDDs?
>>108750599you trust google to optimize your drive...?
>>108751568I meant windows optimizes it
>>108751597>windowsand somehow that's better...?
>>108751597You should disable that garbage because windows will auto set up SSDs to be defragged. Both my 10 and 11 install were defragging BOTH of my m.2s out of the box.
>>108751650optimization isnt defragit deletes unused files or something
>>108751597Yeah windows doesn't require manually defragmentation. Other OSes need frequent manual defragmentation. There's a lot of misinformation about that though
>>108750537It's when the code is full of goblins, which don't let it operate efficiently.
>>108750932Then use something like contig, there is no need to defragment an SSD because that's not how SSDs work, you numpty.
>10+ year old shitIt changes nothing in the cells on the NAND, those are fragmented on purpose anyways.
>>108750511No. Entirely unrelated.
>>108751840You want to defragment the free space, not the files.Mydefrag does have a script that does exactly that mind you.
>>108751650Your shits fucked, it will only enable TRIM for SSDs, not defragment.
Even a heavily fragmented SATA 256GB+ SSD (as long as it has DRAM) is miles ahead of HDD performance. So much that very very few people actually go through the trouble of wiping their entire SSD with a 0 pass wipe twice, once to reset the user exposed NAND, and twice to reset the provisional NAND, because as far as I'm aware this is only real method to actually "defrag" an SSD. Obviously you don't want to do this because it incurs a massive amount of writes.If you want real world performance gains (and reduce write amplification) on your SSD then all you have to do is leave 20-40% empty space to allow for more dynamic SLC caching. As your drive fills up it gets less and less access to dynamic SLC which limits sustained performance and burns through the remaining free space at an accelerated rate.>t. my 256GB 870 evo is 90% full and struggles with large transfers now dropping to 100MB/s after a few GBs
>>108751878That thing makes the files contiguous, effectively "defragmenting" the free space. It doesn't matter regardless, SSDs don't need to spin to find file fragments, so there is no additional wear and tear.
>>108751950>SSDs don't need to spin to find file fragments, so there is no additional wear and tear.The additional wear is on the NAND cells which have finite write cycles.
Just use striping over 10 devices to get increased performance. RAID 0 of course. Trust me.
>>108751963It's not because the entire volume is indexed and available from the get go, not on different parts of a platter/platters.
If you have a good fs like ext4 and dont fill the drive beyond like 90% then the fs will take care of itself. If you move a file or create a new one and delete an old one then the fs will defragment by itself if there is enough space. Windows fs seems to have problems with this it must be a bad design.
>>108750486anon why did you repost my five (5) years old thread?? seriously!!
>>108751995Do you not understand that NAND cells degrade the more time you write on them, so contiguous free space means you can potentially write to less cells, thereby creating less wear on the cells?
>>108752864welcome to the internet, please observe rules 21-24.
>>108752864bot testing engagement with against a known previous postyou have to assume any free/open forum is being raped from every angle by anyone who wants to train any sort of Al
>>108753038>so contiguous free space means you can potentially write to less cellsNo it doesn't, you stupid fucking idiot. I hope you've got your attention fix for the week.
>>108753132>No it doesn't, you stupid fucking idiot.Yes it does.Example: write 50k of data to a single empty 512k NAND cell, or write 50k of data in 50x 1k blocks to 50 different NAND cells because there are empty sectors left from small deleted files. That's potentially 50 SSD writes vs 1 write.Of course modern systems would HOPEFULLY not do asinine shit like that and would write to contiguous free space specifically to avoid this, for examples CoW filesystems specifically would avoid filling empty spaces. But most people still run NTFS and god knows how that would handle this.
>>108750537BSD's "cucked" license is incompatible with their Jewish sensibilities.
>>108750628nope, those are some paleskinian retard traits.
>>108750982trim =/ defrag
>>108750486there's no way min maxing like this matters for modern prosumer drives that read/write at like 7 gigs a second
>>108755399It does somewhat, because those speeds can only be reliably reached if it doesn't have to readdress all the time.In general, when reading from flash memory the read pointer moves automatically as you read bytes. So if it is contiguous data you can just keep sending read commands.If it isn't contiguous you have to interrupt the read commands with another address command. So depending on the size of the sectors and how fragmented the data is you will be adding a percentage of address commands in order to read the file.
>>108750834>>108750564wear... but where? in a place where they never move or multiple paces every time after defrag?
>>108751327none. at best the motor and needle get tired, which is the same from prolonged normal use.
>>108755442The NAND cells degrade slowly over time as they are written to.So when you defrag you're going to taking the data and writing it into a different place.
>>108755455in my experience what kills the nand the most is the speed as you move things. the heat they produce in small electrical lines is the worse culprit. is like a river eroding the soil.
>>108752864holy deadwebsiteroni
>>108755424my point is that they read and write so unbelievably fast anyway that any potential slowdown from being fragmented won't even be noticeable because you're till read/writing at like 4 gigs a second which is still obscenely fast and faster than any other part of your computer
defrag ram and vram
>>108755478>which is still obscenely fast and faster than any other part of your computerExcept RAM.And your CPU caches.
>>108751306>made possibly myYou are an ESL calling a White person stupid.
>>108750550Difference is negligible, you'd need an unreasonable amount of fragmentations before defragging would do anything meaningful for you>>108750597sudo rm - rf /*
>>108755488>defrag ram and vramYou are joking but this used to be a thing, I remember doing it back when I was running 192MB RAM and had to run a ram defrag app which greatly reduced active usage. No clue how it worked in the background, but it did. That was back on Win98SE though.
My SSD is ultra fragmented and speed feels the same. Who fucking cares?>>108752864We are living in a loop of dead memes.
this retard was spamming this nonsense all over /g/ over a year ago
