1 Like
Don’t do that! The filesystem does not necessarily allocate data sequentially. if you have 15% of the filesystem space used, that doesn’t mean that it’s all stored in the first 15% of the sdcard; it can be scattered across the entire sdcard. You don’t have a good backup.
If you want to shrink the filesystem safely, look into resize2fs; this will handle moving data as it shrinks.
4 Likes
Could you please remove the errant instructions so that they don’t get locked there forever.
Thanks,
S
1 Like
It is probably possible to extend the file system if there is unused space. Didn‘t raspian require a reboot to do that anyway?
Anyway, the method I posted in the first post worked perfectly well for me, both by Win32DiskImager and by Linux dd command. I have tested two microSD cards by Win32DiskInmager and two microSD cards by Linux dd and the 2.4 Gb backup from 16 Gb cards worked perfectly well. May be on my microSD cards, the data was not fragmented.
You were lucky. It’s certainly not a method I would use.
I would wait for the full backup to complete.
Personally, I agree with @SweetPea11 and think you should remove this advice.
2 Likes
Anyone who has defragmented a hard drive will have noticed this.
The Win32DiskImager has worked many times for me too, it just takes a long time.
Somewhat counter-intuitively, one of the reasons for scattering where the data is stored is to avoid file-level fragmentation.
1 Like
Indeed!
The move from spinning rust to solid state storage needed a different approach to file arrangement. With virtually zero seek time, there was no longer any benefit in shuffling all the files to one end of the drive and in fact files are deliberately spread across the available space to aid wear leveling.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.