If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#16
|
|||
|
|||
ssd defrag
On Tue, 30 Oct 2018 20:22:47 -0500, Grease Monkey
wrote: Replying to 10/30 Paul AppData might have your email messages. You wouldn't want to delete those in a sloppy or haphazard way. I have many aol versions in AppData that are taking up 14 GB which I will maybe see if I can move to the F: drive to clean up C: since I'm at 2% left of C and the machine is at a crawl. I try to keep one spare disk around, for "bozo backups", where I need to back up something before I ruin it :-) I have a terabyte external seagate hard drive but its not SSD. Using Windirstat or Sequoiaview, you should be able to spot the occasional "porker". I've had file systems before, where the removal of one really big file, was all the maintenance it needed. I can't find it yet but when I do find it I will click on it. With 1TB SSDs going for ~$150 and less, why not just get a generic drive and replace it? The old ones make nice external hard drives, ($10-20 case) and a $20 kit can transfer your files and operating system over to the new drive without a lot of hassle. As an external drive I use mine as a repository for movies and TV shows that I can watch on TV, or just to play around with Linux. |
Ads |
#17
|
|||
|
|||
ssd defrag
In message , Pamela
writes: On 18:49 30 Oct 2018, Char Jackson wrote in news [] Defragging doesn't reclaim space. Wouldn't a defrag reclaim slack space hidden in cluster tips? [] AFAIK, a fragmented file fills all the clusters it uses except the last one, just the same as an unfragmented one. -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf Apologies to [those] who may have been harmed by the scientific inaccuracies in this post. - Roger Tilbury in UMRA, 2018-3-14 |
#18
|
|||
|
|||
ssd defrag
"J. P. Gilliver (John)" wrote:
In message , Pamela writes: On 18:49 30 Oct 2018, Char Jackson wrote in news [] Defragging doesn't reclaim space. Wouldn't a defrag reclaim slack space hidden in cluster tips? [] AFAIK, a fragmented file fills all the clusters it uses except the last one, just the same as an unfragmented one. What - I think - Pamela is hinting at, is that defragmentation can combine the used contents of several partially filled clusters into one or more clusters, thereby potentially freeing up clusters and hence "reclaim space". Simple example: 8KB cluster N is filled with 3000 bytes, 8KB cluster M is filled with 4000 bytes. After a defrag, N has 7000 bytes and M is free, i.e. the defrag reclaimed 8KB of space. Whether Grease Monkey's 'defrag' actaully does this, is unknown as (s)he didn't say *which* 'defrag' (s)he used. |
#19
|
|||
|
|||
ssd defrag
On 4 Nov 2018 15:02:31 GMT, Frank Slootweg
wrote: "J. P. Gilliver (John)" wrote: In message , Pamela writes: On 18:49 30 Oct 2018, Char Jackson wrote in news [] Defragging doesn't reclaim space. Wouldn't a defrag reclaim slack space hidden in cluster tips? [] AFAIK, a fragmented file fills all the clusters it uses except the last one, just the same as an unfragmented one. What - I think - Pamela is hinting at, is that defragmentation can combine the used contents of several partially filled clusters into one or more clusters, thereby potentially freeing up clusters and hence "reclaim space". When files are stored on disk, the only partial clusters are each file's final cluster, so of course you can't combine those. That would corrupt the files that were using those partially filled clusters, so AFAIK, no defragger would attempt to do that. They move things around so that, as much as possible, files are laid out in a contiguous fashion, but they don't/can't free up any space. Where I think the idea of freeing up space via defrag comes from is the edge case where an application wants to write a file to disk, and it demands that the file be contiguous on disk.** You have enough total free space, but not enough contiguous free space, so the operation fails. Some defraggers help in this case because as part of the defragging operation they "pack everything to the left", which is largely unnecessary and is mostly done so that the graphic output looks more pretty. Still, such "packing" would have the effect of creating a larger contiguous space from the many smaller spaces, but the total free space would remain unchanged. **I'm trying to think of an example. Perhaps a container of some kind, such as an encrypted volume or something that holds a virtual disk? I'm struggling to think of an example where a file actually needs to be laid out contiguously. Even the Windows pagefile doesn't care where it lands on disk. Bottom line, if someone is trying to free up disk space, the defragger is the wrong tool for the job. -- Char Jackson |
#20
|
|||
|
|||
ssd defrag
Char Jackson wrote:
On 4 Nov 2018 15:02:31 GMT, Frank Slootweg wrote: "J. P. Gilliver (John)" wrote: In message , Pamela writes: On 18:49 30 Oct 2018, Char Jackson wrote in news [] Defragging doesn't reclaim space. Wouldn't a defrag reclaim slack space hidden in cluster tips? [] AFAIK, a fragmented file fills all the clusters it uses except the last one, just the same as an unfragmented one. What - I think - Pamela is hinting at, is that defragmentation can combine the used contents of several partially filled clusters into one or more clusters, thereby potentially freeing up clusters and hence "reclaim space". When files are stored on disk, the only partial clusters are each file's final cluster, so of course you can't combine those. Yeah, apparently I was confusing things with another - than NTFS - filesystem, where multiple small files or small final parts of files can be stored in one 'cluster'. That probably was HP's HFS filesystem (an implementation of the Berkeley Fast File System for UNIX), which has blocks and fragments, where multiple fragments (f.e. 8, 1KB fragments) make up one (f.e. 8KB) block and each fragment can contain part of a file or a small file. Sigh! And then to think that (UNIX) filesystems was one of my specialities! :-( Well, it has been 15 years, so I'm probably allowed to 'forget' some things. [...] Bottom line, if someone is trying to free up disk space, the defragger is the wrong tool for the job. Unless, you're use a Real File System (TM)! :-) |
#21
|
|||
|
|||
ssd defrag
On Sun, 04 Nov 2018 10:50:51 -0600, Char Jackson
wrote: [snip] **I'm trying to think of an example. Perhaps a container of some kind, such as an encrypted volume or something that holds a virtual disk? I'm struggling to think of an example where a file actually needs to be laid out contiguously. Even the Windows pagefile doesn't care where it lands on disk. IIRC (and I might not), the pagefile USED TO have to be contiguous. I have used non-Windows systems where one could specify that a file be contiguous; I do not know why it was ever needed though. Bottom line, if someone is trying to free up disk space, the defragger is the wrong tool for the job. One possibility would be if a directory spanned more than one cluster but had had files deleted from it such that fewer clusters could hold all of the file entries. This is an extreme case hardly worth worrying about. I have never been able to detect any time difference between before and after defragging so I no longer bother. Sincerely, Gene Wirchenko |
#22
|
|||
|
|||
ssd defrag
On Sun, 04 Nov 2018 10:47:22 -0800, Gene Wirchenko
wrote: I have never been able to detect any time difference between before and after defragging so I no longer bother. Same here. I stopped worrying about fragmentation somewhere around 2002-2003, in the early days of XP. By then, I had moved to bigger, faster, drives, where fragmentation was no more than an academic issue. Even before that, in the days of Norton Utilities in the 90's, I can't say that I noticed a performance difference before versus after, but the disk usage chart was a lot prettier after defragging. Everything was packed nice and tight to the left, at least until the very next time I did *anything*. -- Char Jackson |
#23
|
|||
|
|||
ssd defrag
In message , Gene Wirchenko
writes: [] IIRC (and I might not), the pagefile USED TO have to be contiguous. I have used non-Windows systems where one could specify that a file be contiguous; I do not know why it was ever needed though. If you had sufficiently little RAM that your computer was constantly using the pagefile, which slowed it down considerably (disc access being so much slower than RAM), then anything that further slowed things down could make it closer to unusable. [] -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf "Farc gorillas who live in the plains of the undies ..." - automatic subtitling seen on BBC one o'clock news, 2016-8-25, by Cynthia Hollingworth. |
#24
|
|||
|
|||
ssd defrag
Char Jackson wrote:
On Sun, 04 Nov 2018 10:47:22 -0800, Gene Wirchenko wrote: I have never been able to detect any time difference between before and after defragging so I no longer bother. Same here. I stopped worrying about fragmentation somewhere around 2002-2003, in the early days of XP. By then, I had moved to bigger, faster, drives, where fragmentation was no more than an academic issue. Even before that, in the days of Norton Utilities in the 90's, I can't say that I noticed a performance difference before versus after, but the disk usage chart was a lot prettier after defragging. Everything was packed nice and tight to the left, at least until the very next time I did *anything*. If you turn on NTFS compression for a whole partition (the tick box in "Properties"), then around the 50GB-60GB or so file size, you can run out of fragments to represent the file. It's possible no matter how big the disk, to have a problem with fragments. But, it only happens with the crappy NTFS compression feature. I don't regularly use compression, but I think it did hit me once when trying to get a bit more mileage out of a storage device. Paul |
#25
|
|||
|
|||
ssd defrag
On 11/4/18 10:50 AM, Char Jackson wrote:
[snip] **I'm trying to think of an example. Perhaps a container of some kind, such as an encrypted volume or something that holds a virtual disk? I'm struggling to think of an example where a file actually needs to be laid out contiguously. Even the Windows pagefile doesn't care where it lands on disk. IIRC, some early versions of DOS required the executable code files (IO.SYS, MSDOS.SYS) to be contiguous (I think it's so the boot code can just read multiple sectors into memory). Bottom line, if someone is trying to free up disk space, the defragger is the wrong tool for the job. -- 51 days until the winter celebration (Tue Dec 25, 2018 12:00:00 AM for 1 day). Mark Lloyd http://notstupid.us/ "The 'evangel' died on the cross. What has been called 'evangel' from that moment was actually the opposite of that which *he* had lived: '*ill* tidings,' a *dysangel*." [Nietzsche] |
#26
|
|||
|
|||
ssd defrag
On Sun, 04 Nov 2018 18:55:29 -0500, Paul wrote:
Char Jackson wrote: On Sun, 04 Nov 2018 10:47:22 -0800, Gene Wirchenko wrote: I have never been able to detect any time difference between before and after defragging so I no longer bother. Same here. I stopped worrying about fragmentation somewhere around 2002-2003, in the early days of XP. By then, I had moved to bigger, faster, drives, where fragmentation was no more than an academic issue. Even before that, in the days of Norton Utilities in the 90's, I can't say that I noticed a performance difference before versus after, but the disk usage chart was a lot prettier after defragging. Everything was packed nice and tight to the left, at least until the very next time I did *anything*. If you turn on NTFS compression for a whole partition (the tick box in "Properties"), then around the 50GB-60GB or so file size, you can run out of fragments to represent the file. It's possible no matter how big the disk, to have a problem with fragments. But, it only happens with the crappy NTFS compression feature. I don't regularly use compression, but I think it did hit me once when trying to get a bit more mileage out of a storage device. Good info, but the last time I was in a position where I was running out of disk space, Stacker was the hot ticket, later replaced (briefly) by Microsoft's DoubleSpace utility. Since then, I've managed to keep ahead of my storage needs by adding ever larger drives. -- Char Jackson |
#27
|
|||
|
|||
ssd defrag
On 5-11-2018 1:46, Mark Lloyd wrote:
On 11/4/18 10:50 AM, Char Jackson wrote: [snip] **I'm trying to think of an example. Perhaps a container of some kind, such as an encrypted volume or something that holds a virtual disk? I'm struggling to think of an example where a file actually needs to be laid out contiguously. Even the Windows pagefile doesn't care where it lands on disk. IIRC, some early versions of DOS required the executable code files (IO.SYS, MSDOS.SYS) to be contiguous (I think it's so the boot code can just read multiple sectors into memory). Bottom line, if someone is trying to free up disk space, the defragger is the wrong tool for the job. Not only contiguous, but in a preset location as well. Which the "sys"command did for you on an empty drive. |
#28
|
|||
|
|||
ssd defrag
On 11/4/18 11:08 PM, Sjouke Burry wrote:
[snip] IIRC, some early versions of DOS required the executable code files (IO.SYS, MSDOS.SYS) to be contiguous (I think it's so the boot code can just read multiple sectors into memory). Bottom line, if someone is trying to free up disk space, the defragger is the wrong tool for the job. Not only contiguous, but in a preset location as well. Which the "sys"command did for you on an empty drive. For that reason, SYS would fail if there were already files on the disk. I forgot just when they changed that. -- 50 days until the winter celebration (Tue Dec 25, 2018 12:00:00 AM for 1 day). Mark Lloyd http://notstupid.us/ "There are ten church members by inheritance for every one by conviction." [Anonymous] |
#29
|
|||
|
|||
ssd defrag
J. P. Gilliver (John) wrote:
In message , Grease Monkey writes: I have an old dell xpsl702x laptop with two 256GB ssd drives which are full and dell won't sell me any larger ssd drives. Defrag has been running for almost day now. Is it worth defragging to get space back or is defragging ssd not going to gain much space when it finally finishes. With modern OSs and drive sizes, defragging doesn't recover that much space. But the main thing is, defragging on SSD drives might significantly reduce their life, as they have significantly fewer write cycles than HDs. If you really want to defrag them, _move_ their contents to another drive (preferably an HD one), then move them back: this will only involve one write (for most of their sectors; two to their directory sectors). [Obviously if one of them is the OS drive, you can't move all the files in this way, but it may still be worth doing.] Has it gotten to the point now that SSDs are considered to be just as reliable, long term, as the standard hard drives, even with all the consequent writes and rewrites (also potentially limiting the SSDs "longevity")? (I mean when used as your main drive)? But maybe SSDs still haven't been out quite long enough to yet assess their long term reliability and longevity. |
#30
|
|||
|
|||
ssd defrag
Bill in Co wrote:
Has it gotten to the point now that SSDs are considered to be just as reliable, long term, as the standard hard drives, even with all the consequent writes and rewrites (also potentially limiting the SSDs "longevity")? (I mean when used as your main drive)? But maybe SSDs still haven't been out quite long enough to yet assess their long term reliability and longevity. It's gotten to the point you can use them. They don't insta-brick like they once did. The user "John Doe" had one insta-brick on him. They're still potentially susceptible to power events. Check the SMART table, to see if "the drive thinks you've been abusing it". There's a field for that (abrupt power loss). For example, even if I safely remove an SSD connected to a USB to SATA 2.5" adapter, the SSD counts my unplugging the cable after Safely Remove as an abrupt power loss. It should not do that, if the command was making it through the protocol layers properly. (The drive should have been placed in a "spun down" state.) You still need to back them up. Don't leave your data files on one. Leave your OS on the SSD, move your data files to the HDD. The "end of life" of an HDD today, is much more gentle than the "brick state" an Intel SSD drive enters at the end of its wear life counter. Intel will allow neither read nor write, when the computed amount of write cycles is exceeded. Samsung will likely allow the drive to continue, so you could, say, do a last backup. Intel SSDs don't allow even that. Dig a hole in the back yard, and throw your Intel SSD in the hole, when that happens. "No data recovery for you." Always research the "end-of-life" behavior of any SSD you buy, so your backup strategy has you covered. Paul |
Thread Tools | |
Display Modes | |
|
|