Live data from Hacker News

Show HN: I missed the moving blocks, so I built a real Linux disk defragmenter

github.com

71–78 of 78 posts

Re: Show HN: I missed the moving blocks, so I built a real Linux disk defragmenter

#71
post #23
post #19

Earlier quoted context omitted.

Is it possible to determine which sectors are physically sequential given remapping for wear-leveling? Otherwise the claimed defragmentation here is not actually resulting in sequential data.

You cannot directly inspect the degree of fragmentation, because it has less to do with being contiguous in the Logical Block Address (LBA) space and more to do with having been written at the same time. To properly defragment a file on a SSD, you pretty much need to sequentially re-write the whole file in one go, to a newly-allocated part of the drive's LBA space.

> to a newly-allocated part of the drive's LBA space

Which is rather a case for home use, not practical for highly parallel access industrial use cases. That's why the issue became a research topic. For the first time I saw a proof that the "fact" SSDs do not need defragmentation is actually a myth. Well, you still want to avoid explicit defragmentation (waste of time and SSD lifetime) by filesystem driver submitting additional hints (using new NVMe extensions) to the SSD controller about what blocks belong to the same file, so that SSD can place them for an optimal sequential access with properly interleaving (not necessary strictly physically consecutively whatever this means on SSD).

https://www.usenix.org/conference/fast24/presentation/jun

Re: Show HN: I missed the moving blocks, so I built a real Linux disk defragmenter

#72
post #54

Earlier quoted context omitted.

I'm pretty sure you don't understand how threads in discussion works. But, hey. Atleast you can write ~1000 chars with absolutelly no substance fo prove that you know nothing about the topic. What a life to live.

You pretty being sure of that and not understanding the relevance of the reply, makes me very sure that you are the one without a clue. And you sound like a bit of dick on top. I wish you luck in your future endeavours.

One more comment of no substance.

Yes ... I didn't understand the relevance of your previous comment because it didn't have any substance.

Your inability to notice T.R.I.M. being standard on all SSD's for like 10+ years doesn't make me "one without the clue" or "bit of a dick".

It just means that you have memory of a fish, doesn't have intellect to produce anything with atleast a hint of relevance.

But you really excel at being butthurt whenever (as always) your desperate attempt to portray yourself knowledgeable fail.

You really don't wish me luck. I really don't need your wishes. And I don't need luck, I'm perfectly fine with what I've managed so far with my own effort. Something basement dweller like you can hardly understand.

Re: Show HN: I missed the moving blocks, so I built a real Linux disk defragmenter

#73
post #43

Neat! I have several questions here. First of all, why does Linux not need defragmentation? Second, is it actually true that it doesn't need it? The readme implies that this defragmenter (for Linux) produces actual benefits. Third, it says the benefits exist even on NVMe, i.e. on SSDs? I thought defragging was relevant for spinny disks only? Thanks

[flagged]

Re: Show HN: I missed the moving blocks, so I built a real Linux disk defragmenter

#74
post #72

Earlier quoted context omitted.

You pretty being sure of that and not understanding the relevance of the reply, makes me very sure that you are the one without a clue. And you sound like a bit of dick on top. I wish you luck in your future endeavours.

One more comment of no substance. Yes ... I didn't understand the relevance of your previous comment because it didn't have any substance. Your inability to notice T.R.I.M. being standard on all SSD's for like 10+ years doesn't make me "one without the clue" or "bit of a dick". It just means that you have memory of a fish, doesn't have intellect to produce anything with atleast a hint of relevance. But you really exc…

> You really don't wish me luck.

Oh, but I do. Please note that I do not specify what variety of luck I am wishing.

> I really don't need your wishes.

You have them anyway. Enjoy.

> But you really excel at being butthurt

My butt is just fine, thanks. I can send a picture as proof if you are really interested.

> Your inability to notice T.R.I.M.

I know about TRIM. I also know it is irrelevant to the performance issue being discussed. TRIM works over the SSD's native block size which is much larger (usually at least 512KB, could be several MB depending on controller and memory layout) than the filesystem's granularity (usually 4K or of similar order). The OS can ask the drive to TRIM smaller parts all it likes, and nothing will happen because to do that the drive would need to relocate the rest of the block causing a full (ssd native sized) block READ+WRITE.

The issue defragmenting in this instance deals with is how filesystem blocks are arranged within the SSD's blocks: keeping those close by in the same block. The order within the block won't matter, but if due to fragmentation the filesystem blocks of a file are spread through many SSD blocks then reading that file will take longer than if they aren't. TRIM does nothing here, TRIM is not aware of the filesystem layout.

> "bit of a dick"

Sorry, am I underestimating? Should that have been a lot of a dick?

Re: Show HN: I missed the moving blocks, so I built a real Linux disk defragmenter

#75

Earlier quoted context omitted.

> My partner complains about me closing apps on my phone consistently. I'd be curious to know the reqson why she would care on her own phone and why it would be an issue on someone else's phone?

At least on iPhone, it basically doesn't do anything. Apple aggressively kills all background apps automatically. the "open" apps in the switcher are almost always just screenshots of previously-open-but-now-closed apps. if it was recent, the latest app or two in the switcher might actually be open, but rarely more than that. Despite this, many of my relatives have somehow learned this habit of opening the switcher a…

If you just have every app in the switcher, it becomes useless too.

Re: Show HN: I missed the moving blocks, so I built a real Linux disk defragmenter

#76
post #72

Earlier quoted context omitted.

One more comment of no substance. Yes ... I didn't understand the relevance of your previous comment because it didn't have any substance. Your inability to notice T.R.I.M. being standard on all SSD's for like 10+ years doesn't make me "one without the clue" or "bit of a dick". It just means that you have memory of a fish, doesn't have intellect to produce anything with atleast a hint of relevance. But you really exc…

> You really don't wish me luck. Oh, but I do. Please note that I do not specify what variety of luck I am wishing. > I really don't need your wishes. You have them anyway. Enjoy. > But you really excel at being butthurt My butt is just fine, thanks. I can send a picture as proof if you are really interested. > Your inability to notice T.R.I.M. I know about TRIM. I also know it is irrelevant to the performance issue…

Anyone who knows what SSD's have reserve capacity understands that none of what you wrote makes any sense.

But HEY, you've learned something new ... reserve capacity. Just like you did about TRIM.

Now you can update your "knowledge" with new bullshit.

Keep us updated. Your desperate backpaddling attempts are hilarious.

Re: Show HN: I missed the moving blocks, so I built a real Linux disk defragmenter

#77
post #27

Earlier quoted context omitted.

This is literally always how iOS has worked. You can refer to the application lifecycle documentation: https://developer.apple.com/documentation/uikit/managing-you...

What point are you trying to make. The documentation doesn't say the OS only keeps a single app process running at a time.

The document is clear that the expectation from the developer is that you need to be ready for your app to be snapshotted and frozen/killed at any moment when it is not on the foreground.

Re: Show HN: I missed the moving blocks, so I built a real Linux disk defragmenter

#78
post #76

Earlier quoted context omitted.

> You really don't wish me luck. Oh, but I do. Please note that I do not specify what variety of luck I am wishing. > I really don't need your wishes. You have them anyway. Enjoy. > But you really excel at being butthurt My butt is just fine, thanks. I can send a picture as proof if you are really interested. > Your inability to notice T.R.I.M. I know about TRIM. I also know it is irrelevant to the performance issue…

Anyone who knows what SSD's have reserve capacity understands that none of what you wrote makes any sense. But HEY, you've learned something new ... reserve capacity. Just like you did about TRIM. Now you can update your "knowledge" with new bullshit. Keep us updated. Your desperate backpaddling attempts are hilarious.

I also knew about reserve capacity. And I know, that like TRIM, it has no direct effect on the performance issue being discussed here (cause by file blocks being spread around larger blocks in the SSD's granularity).

I have not back peddled at all. You are the one bringing up new concepts randomly.

> Keep us updated.

“us” is just me and you, your first childish post has long since been flagged so no one else will be seeing this.

Post reply on HN