Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.microsoft.windows > #2634 > unrolled thread

Using Windows to make Android smoother

Back to article view | Back to alt.comp.microsoft.windows

Contents

  Using Windows to make Android smoother Andrews <andrews@spam.net> - 2024-10-23 21:54 +0000
    Re: Using Windows to make Android smoother Paul <nospam@needed.invalid> - 2024-10-24 03:20 -0400
      Re: Using Windows to make Android smoother "Carlos E.R." <robin_listas@es.invalid> - 2024-10-24 16:12 +0200
        Re: Using Windows to make Android smoother "...winston" <winstonmvp@gmail.com> - 2024-10-24 13:20 -0400
          Re: Using Windows to make Android smoother Harry S Robins <stanleyrobins@nothere.uk> - 2024-10-24 13:00 -0500
            Re: Using Windows to make Android smoother "...winston" <winstonmvp@gmail.com> - 2024-10-24 14:12 -0400
            Re: Using Windows to make Android smoother Arno Welzel <usenet@arnowelzel.de> - 2024-10-26 12:10 +0200
              Re: Using Windows to make Android smoother "Carlos E.R." <robin_listas@es.invalid> - 2024-10-26 15:56 +0200
              Re: Using Windows to make Android smoother Paul <nospam@needed.invalid> - 2024-10-26 14:09 -0400
                Re: Using Windows to make Android smoother Arno Welzel <usenet@arnowelzel.de> - 2024-10-28 16:53 +0100
                  Re: Using Windows to make Android smoother "Carlos E.R." <robin_listas@es.invalid> - 2024-11-01 09:19 +0100
          Re: Using Windows to make Android smoother Paul <nospam@needed.invalid> - 2024-10-24 14:33 -0400
            Re: Using Windows to make Android smoother "...winston" <winstonmvp@gmail.com> - 2024-10-24 21:13 -0400
              Re: Using Windows to make Android smoother Paul <nospam@needed.invalid> - 2024-10-25 01:35 -0400
                Re: Using Windows to make Android smoother Frank Slootweg <this@ddress.is.invalid> - 2024-10-25 10:15 +0000
                Re: Using Windows to make Android smoother "Carlos E.R." <robin_listas@es.invalid> - 2024-10-25 15:11 +0200
                  Re: Using Windows to make Android smoother Paul <nospam@needed.invalid> - 2024-10-25 11:02 -0400
                    Olde Disk Drives (was: Re: Using Windows to make Android smoother "Kerr-Mudd, John" <admin@127.0.0.1> - 2024-10-25 17:35 +0100
      Re: Using Windows to make Android smoother Andrews <andrews@spam.net> - 2024-10-24 17:15 +0000
        Re: Using Windows to make Android smoother Paul <nospam@needed.invalid> - 2024-10-24 14:42 -0400
    Re: Using Windows to make Android smoother Andrews <andrews@spam.net> - 2024-10-24 17:35 +0000
      Re: Using Windows to make Android smoother "...winston" <winstonmvp@gmail.com> - 2024-10-24 14:35 -0400
    Re: Using Windows to make Android smoother Andrews <andrews@spam.net> - 2024-10-25 18:41 +0000
    Re: Using Windows to make Android smoother Andrews <andrews@spam.net> - 2024-11-01 06:26 +0000
      Re: Using Windows to make Android smoother Andrews <andrews@spam.net> - 2024-11-01 13:56 +0000

Page 1 of 2  [1] 2  Next page →

#2634 — Using Windows to make Android smoother

I need a bigger sd card - I spent years for this moment by using Windows to
make Android sdcard swaps smoother and drama reduced experiences for all.

Some questions... 

Does a Windows "Quick Format" work as well as the slow format?
Does the format type matter when the sd card is to be used in a phone?
Do you change the volume label when you format on Windows for Android?
 <https://i.postimg.cc/dVtqQ9dX/sd01.jpg>

Some background... 

In May of 2021 I received from T-Mobile a new free Samsung Galaxy A32-5G
with 64GB of internal storage, which I broke twice under warranty so
T-Mobile replaced it twice within the first two years where all I had to do
was swap out the old 64GB sd card and put it into the new phone each time.

Everything came over seamlessly without the Internet involved, which, if
you know me, is something I strive to avoid when copying personal data.

But this is different than swapping out the phone. This is swapping out the
sd card which has been in use since 2021 with all my data sitting on it.
 <https://i.postimg.cc/fWX7wzcg/filesys.jpg>

Of course, I did two things years ago to plan for this type of event:
1. I formatted all my sd cards on Windows to the same volume name, and, 
2. I put all my data under a single folder on the external sd card.

Those two simple things, I hope, will make this sd swap, uneventful.
a. Format the sd card on Windows to "0000-0001"
b. on Windows, create a top-level directory of "0001"
   Note: The names don't matter as long as they're consistent.

I just bought from Amazon a 128GB three-pack with reader at about $10 each.
And, while a quick format on Windows takes a couple of seconds, a slow
format takes quite a bit longer - it's still running on my old desktop.

Did I need that slow format?
Is the default of XFat (128kbyte allocation unit) an OK setting for phones?
Is the type of card I bought OK for phones? 

The (slow) format is still running, but when it's done, I'm going to copy
my "0001" data over from the old sdcard in the phone, to the new sdcard.

And then I'm going to swap out the old sdcard for the new one for, what I
hope to be a seamless experience using Windows to make Android smoother.

Wish me luck!

[toc] | [next] | [standalone]

#2635

On Wed, 10/23/2024 5:54 PM, Andrews wrote:
> I need a bigger sd card - I spent years for this moment by using Windows to
> make Android sdcard swaps smoother and drama reduced experiences for all.
> 
> Some questions...
> Does a Windows "Quick Format" work as well as the slow format?
> Does the format type matter when the sd card is to be used in a phone?
> Do you change the volume label when you format on Windows for Android?
> <https://i.postimg.cc/dVtqQ9dX/sd01.jpg>
> 
> Some background...
> In May of 2021 I received from T-Mobile a new free Samsung Galaxy A32-5G
> with 64GB of internal storage, which I broke twice under warranty so
> T-Mobile replaced it twice within the first two years where all I had to do
> was swap out the old 64GB sd card and put it into the new phone each time.
> 
> Everything came over seamlessly without the Internet involved, which, if
> you know me, is something I strive to avoid when copying personal data.
> 
> But this is different than swapping out the phone. This is swapping out the
> sd card which has been in use since 2021 with all my data sitting on it.
> <https://i.postimg.cc/fWX7wzcg/filesys.jpg>
> 
> Of course, I did two things years ago to plan for this type of event:
> 1. I formatted all my sd cards on Windows to the same volume name, and, 2. I put all my data under a single folder on the external sd card.
> 
> Those two simple things, I hope, will make this sd swap, uneventful.
> a. Format the sd card on Windows to "0000-0001"
> b. on Windows, create a top-level directory of "0001"
>   Note: The names don't matter as long as they're consistent.
> 
> I just bought from Amazon a 128GB three-pack with reader at about $10 each.
> And, while a quick format on Windows takes a couple of seconds, a slow
> format takes quite a bit longer - it's still running on my old desktop.
> 
> Did I need that slow format?
> Is the default of XFat (128kbyte allocation unit) an OK setting for phones?
> Is the type of card I bought OK for phones?
> The (slow) format is still running, but when it's done, I'm going to copy
> my "0001" data over from the old sdcard in the phone, to the new sdcard.
> 
> And then I'm going to swap out the old sdcard for the new one for, what I
> hope to be a seamless experience using Windows to make Android smoother.
> 
> Wish me luck!

You would buy an SD card with static and dynamic wear leveling.

A quick format is good enough. It writes and puts a FAT or $MFT on the partition.

The slow format does the same, except it includes a read-verify of the surface.

To "erase" a storage device, diskpart "clean all" will write the entire
surface with zeros. Or dd.exe can write the surface with zeros.

It's hard to get good info about SD, like the wear leveling scheme.
If it has both static and dynamic wear leveling, it could last longer
because then you can't really burn a hole in it as easily.

The difference to a USB flash stick, could be the binning of the flash.
Maybe the flash is a bit better. USB sticks could be pretty low quality.
Like purchasing a 16GB USB key, could be a 32GB chip with half of it
pinned off because it didn't pass.

SD has limits on both write speed and read speed. The physical interface
is pretty "thin", and that's why it can't read faster than it does.
There is a promise that coming SD cards will have one lane PCI Express
interfaces, which should make then read better. But when that is done,
the writing won't be faster. Just as the worse USB3 flash sticks might be
100MB/sec read and 10MB/sec write. My Rally2 can write at about 16MB/sec,
but it doesn't read in a big hurry. Whereas USB3 sticks can have larger
differences between read and write. And some USB, have "uneven" behavior.
I've got a stick here now, it stalls for a while, it does a tiny bit of
writes, then stalls some more. My SD doesn't do that.

   Paul

[toc] | [prev] | [next] | [standalone]

#2636

On 2024-10-24 09:20, Paul wrote:
> On Wed, 10/23/2024 5:54 PM, Andrews wrote:
>> I need a bigger sd card - I spent years for this moment by using Windows to
>> make Android sdcard swaps smoother and drama reduced experiences for all.
>>
>> Some questions...
>> Does a Windows "Quick Format" work as well as the slow format?
>> Does the format type matter when the sd card is to be used in a phone?
>> Do you change the volume label when you format on Windows for Android?
>> <https://i.postimg.cc/dVtqQ9dX/sd01.jpg>
>>
>> Some background...

...

>> Did I need that slow format?
>> Is the default of XFat (128kbyte allocation unit) an OK setting for phones?
>> Is the type of card I bought OK for phones?
>> The (slow) format is still running, but when it's done, I'm going to copy
>> my "0001" data over from the old sdcard in the phone, to the new sdcard.
>>
>> And then I'm going to swap out the old sdcard for the new one for, what I
>> hope to be a seamless experience using Windows to make Android smoother.
>>
>> Wish me luck!
> 
> You would buy an SD card with static and dynamic wear leveling.
> 
> A quick format is good enough. It writes and puts a FAT or $MFT on the partition.
> 
> The slow format does the same, except it includes a read-verify of the surface.

Doesn't it fill everything with zeroes as well? Or erase all sectors? 
That reduces the life of the card or stick.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#2638

Carlos E.R. wrote:
> On 2024-10-24 09:20, Paul wrote:
>> On Wed, 10/23/2024 5:54 PM, Andrews wrote:
>>> I need a bigger sd card - I spent years for this moment by using 
>>> Windows to
>>> make Android sdcard swaps smoother and drama reduced experiences for 
>>> all.
>>>
>>> Some questions...
>>> Does a Windows "Quick Format" work as well as the slow format?
>>> Does the format type matter when the sd card is to be used in a phone?
>>> Do you change the volume label when you format on Windows for Android?
>>> <https://i.postimg.cc/dVtqQ9dX/sd01.jpg>
>>>
>>> Some background...
> 
> ...
> 
>>> Did I need that slow format?
>>> Is the default of XFat (128kbyte allocation unit) an OK setting for 
>>> phones?
>>> Is the type of card I bought OK for phones?
>>> The (slow) format is still running, but when it's done, I'm going to 
>>> copy
>>> my "0001" data over from the old sdcard in the phone, to the new sdcard.
>>>
>>> And then I'm going to swap out the old sdcard for the new one for, 
>>> what I
>>> hope to be a seamless experience using Windows to make Android smoother.
>>>
>>> Wish me luck!
>>
>> You would buy an SD card with static and dynamic wear leveling.
>>
>> A quick format is good enough. It writes and puts a FAT or $MFT on the 
>> partition.
>>
>> The slow format does the same, except it includes a read-verify of the 
>> surface.
> 
> Doesn't it fill everything with zeroes as well? Or erase all sectors? 
> That reduces the life of the card or stick.
> Writing zeros for full format option was introduced with Vista. 
Applicable also to all later Windows o/s.
Full format
  - files erased
  - writes zeros to the whole disk
  - drive scanned for bad sectors(does not fix bad sectors)
  - new root directory and file system


-- 
...w¡ñ§±¤ñ

[toc] | [prev] | [next] | [standalone]

#2640

On Thu, 24 Oct 2024 13:20:23 -0400, ...winston wrote:

>>> You would buy an SD card with static and dynamic wear leveling.
>>>
>>> A quick format is good enough. It writes and puts a FAT or $MFT on the 
>>> partition.
>>>
>>> The slow format does the same, except it includes a read-verify of the 
>>> surface.
>> 
>> Doesn't it fill everything with zeroes as well? Or erase all sectors? 
>> That reduces the life of the card or stick.
>> Writing zeros for full format option was introduced with Vista. 
> Applicable also to all later Windows o/s.
> Full format
>   - files erased
>   - writes zeros to the whole disk
>   - drive scanned for bad sectors(does not fix bad sectors)
>   - new root directory and file system

If a Windows full format doesn't fix bad sectors, what does it do to them?

I always thought a format put a "jumper" so that bad sectors were ignored.

Is that "jumper" (or whatever it's really called) considered a fix?
Or is a fix something else?

[toc] | [prev] | [next] | [standalone]

#2641

Harry S Robins wrote:
> On Thu, 24 Oct 2024 13:20:23 -0400, ...winston wrote:
> 
>>>> You would buy an SD card with static and dynamic wear leveling.
>>>>
>>>> A quick format is good enough. It writes and puts a FAT or $MFT on 
>>>> the partition.
>>>>
>>>> The slow format does the same, except it includes a read-verify of 
>>>> the surface.
>>>
>>> Doesn't it fill everything with zeroes as well? Or erase all sectors? 
>>> That reduces the life of the card or stick.
>>> Writing zeros for full format option was introduced with Vista. 
>> Applicable also to all later Windows o/s.
>> Full format
>>   - files erased
>>   - writes zeros to the whole disk
>>   - drive scanned for bad sectors(does not fix bad sectors)
>>   - new root directory and file system
> 
> If a Windows full format doesn't fix bad sectors, what does it do to them?
> 
> I always thought a format put a "jumper" so that bad sectors were ignored.
> 
> Is that "jumper" (or whatever it's really called) considered a fix?
> Or is a fix something else?

Marks as bad, isolating from future use.
  - marking as bad and ignored in the future, is not a 'fixing bad 
sector' condition.
  => If its bad, it remains bad and prevented for future use.

Chkdisk, another tool, doesn't necessarily fix bad sectors either. Ymmv 
with use.
  - the most likely end result, is recovering any possible data found in 
a bad sector, move to a known good sector, then mark bad sector from 
future use.

-- 
...w¡ñ§±¤ñ

[toc] | [prev] | [next] | [standalone]

#2652

Harry S Robins, 2024-10-24 20:00:

[...]
> If a Windows full format doesn't fix bad sectors, what does it do to them?

It will verify every data block, so "bad" blocks can get recorded so
they don't get used any longer.

> I always thought a format put a "jumper" so that bad sectors were ignored.

Yes - but this depends on the medium used. Flash storage media like SSDs
have their own controller which does bad block mapping on their own and
use spare blocks (usually a few percent of the capacity are reserved for
this) as substitute for defect ones. However SD cards are quite "dumb"
and 100% of the capacity is used for data - so bad blocks need to be
recorded as part of the filesystem during "long" formatting.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#2653

On 2024-10-26 12:10, Arno Welzel wrote:
> Harry S Robins, 2024-10-24 20:00:
> 
> [...]
>> If a Windows full format doesn't fix bad sectors, what does it do to them?
> 
> It will verify every data block, so "bad" blocks can get recorded so
> they don't get used any longer.
> 
>> I always thought a format put a "jumper" so that bad sectors were ignored.
> 
> Yes - but this depends on the medium used. Flash storage media like SSDs
> have their own controller which does bad block mapping on their own and
> use spare blocks (usually a few percent of the capacity are reserved for
> this) as substitute for defect ones. However SD cards are quite "dumb"
> and 100% of the capacity is used for data - so bad blocks need to be
> recorded as part of the filesystem during "long" formatting.

I seem to recall that the old MsDOS chkdisk (not sure of the name) could 
mark bad sectors on floppies and such.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#2654

On Sat, 10/26/2024 6:10 AM, Arno Welzel wrote:
> Harry S Robins, 2024-10-24 20:00:
> 
> [...]
>> If a Windows full format doesn't fix bad sectors, what does it do to them?
> 
> It will verify every data block, so "bad" blocks can get recorded so
> they don't get used any longer.
> 
>> I always thought a format put a "jumper" so that bad sectors were ignored.
> 
> Yes - but this depends on the medium used. Flash storage media like SSDs
> have their own controller which does bad block mapping on their own and
> use spare blocks (usually a few percent of the capacity are reserved for
> this) as substitute for defect ones. However SD cards are quite "dumb"
> and 100% of the capacity is used for data - so bad blocks need to be
> recorded as part of the filesystem during "long" formatting.
> 

$BADCLUS can be updated at two times. By doing the "long format",
you can update $BADCLUS before files are put on a drive. By using the
scanning option in CHKDSK, you can mark off clusters via $BADCLUS
(presumably trashing a file at the same time, a file that was already
trashed so no big deal).

But with automatic sparing at the hard drive level, the need to
scan and add clusters to $BADCLUS is mostly removed. The only
time a disk gets a hard CRC error, is when that area of the
disk runs out of spares for repairs.

I had four CRC errors on a WD Blue in my Optiplex Refurb.
Re-writing the entire surface of the disk, flushed the errors.
There was an opportunity for the bad blocks to be spared out.
If I had done a $BADCLUS scan when the immediate problem
occurred, four clusters would be marked off as unusable,
and then there would be no need for the hard drive to
spare out the sector. But then, I have slightly less
space on the drive as a result.

You then have to ask yourself, what is the best practice for the
thing. Nothing springs to mind, except to say I would start
with an HDTune bad block scan, which would show the four bad sectors,
but without the side effect of using $BADCLUS. Then I would be in
a position to decide whether "washing and rinsing" the surface
was enough, or whether "digging divots" in the surface was needed.

When I checked, two of the CRC errors were in white space,
and two of the CRC errors were real files. By knowing what
the real files were, I could replace them. The white space
errors, it would not matter what happened there, so I had
only half the work to do (just dig up two files).

To work out what the files are, I use a copy of nfi.exe which
has LBA numbers. and then I can map an address to a file. Then
I can take a hex editor, open the "file" and notice the first
sector has stale data in it, the second sector has a CRC error.
This is the pattern you see on a "high fly" error. The head was
so far above the surface on the first sector, the mag field from
the write couldn't even couple into the surface.

You can push the entire partition into $BADCLUS. It has
the capacity to do that. if there is a pathological problem
via the controller, you could cause every file on a partition
to disappear.

In the past, a pathological situation for CHKDSK, occurs
when you pull the IDE ribbon cable half way off a drive. I
actually managed to do that one day, but I could feel that
I had bumped into something, and spotted it in time.
If you notice the disk has problems on the next boot,
you may be tempted to do a CHKDSK. It tries to rewrite stuff.
It modifies a hundred thousand things. Your disk is... trashed.
(None of the writes done, are good, because the cable is half off.)
It is for this sort of failing (an I/O issue), that CHKDSK
is the wrong tool. Other situations, the Microsoft declaration
that "stopping a CHKDSK run, causes no more damage than was there in
the first place", that statement can be true as long as the
I/O is in perfect working condition.

Summary: Firstly, a backup is your friend.
         HDTune can do a bad block scan, indicating your trouble situation.
         (I use more tools than this, this is just a canary run to prove trouble awaits.)
         ddrescue (gddrescue package in Ubuntu) can back up a damaged disk.
         [Normally you would use Macrium if the disk was undamaged, no CRCs]
         Since you have your backup now, you have my permission to run CHKDSK :-)
         Let the chainsaw at it.

         If $BADCLUS has a use in modern times, I don't really know where it
         fits. It was invented for a time when disks had less internal automation.
         Maybe it covers floppies well (our floppies at work used a similar philosophy).
         But generally speaking, it is my opinion that when the signs are
         that a sick disk drive is involved, you should make it personal and
         work at a lower level, to reduce the damage level. $BADCLUS, scanning
         disks for bad clusters, is just a bad economy. If your disk really
         sucks this badly, replace it. There are yoyos who will move a partition
         away from a CRC damaged area, but then those same individuals don't believe
         in backups, and they will be wearing that sad face when it dies entirely.

         The WD Blue 250GB in this story, got replaced. Cost $65 at the time for a WD Black 1TB.

   Paul

[toc] | [prev] | [next] | [standalone]

#2658

Paul, 2024-10-26 20:09:

> On Sat, 10/26/2024 6:10 AM, Arno Welzel wrote:
>> Harry S Robins, 2024-10-24 20:00:
>>
>> [...]
>>> If a Windows full format doesn't fix bad sectors, what does it do to them?
>>
>> It will verify every data block, so "bad" blocks can get recorded so
>> they don't get used any longer.
>>
>>> I always thought a format put a "jumper" so that bad sectors were ignored.
>>
>> Yes - but this depends on the medium used. Flash storage media like SSDs
>> have their own controller which does bad block mapping on their own and
>> use spare blocks (usually a few percent of the capacity are reserved for
>> this) as substitute for defect ones. However SD cards are quite "dumb"
>> and 100% of the capacity is used for data - so bad blocks need to be
>> recorded as part of the filesystem during "long" formatting.
>>
> 
> $BADCLUS can be updated at two times. By doing the "long format",
> you can update $BADCLUS before files are put on a drive. By using the
> scanning option in CHKDSK, you can mark off clusters via $BADCLUS
> (presumably trashing a file at the same time, a file that was already
> trashed so no big deal).

JFTR: $BADCLUS is specific for NTFS. However SD cards are usually not
formatted using NTFS. But FAT and ExFAT also have mechanisms to record
bad blocks which should not be used any longer.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#2660

On 2024-10-28 16:53, Arno Welzel wrote:
> Paul, 2024-10-26 20:09:
> 
>> On Sat, 10/26/2024 6:10 AM, Arno Welzel wrote:
>>> Harry S Robins, 2024-10-24 20:00:
>>>
>>> [...]
>>>> If a Windows full format doesn't fix bad sectors, what does it do to them?
>>>
>>> It will verify every data block, so "bad" blocks can get recorded so
>>> they don't get used any longer.
>>>
>>>> I always thought a format put a "jumper" so that bad sectors were ignored.
>>>
>>> Yes - but this depends on the medium used. Flash storage media like SSDs
>>> have their own controller which does bad block mapping on their own and
>>> use spare blocks (usually a few percent of the capacity are reserved for
>>> this) as substitute for defect ones. However SD cards are quite "dumb"
>>> and 100% of the capacity is used for data - so bad blocks need to be
>>> recorded as part of the filesystem during "long" formatting.
>>>
>>
>> $BADCLUS can be updated at two times. By doing the "long format",
>> you can update $BADCLUS before files are put on a drive. By using the
>> scanning option in CHKDSK, you can mark off clusters via $BADCLUS
>> (presumably trashing a file at the same time, a file that was already
>> trashed so no big deal).
> 
> JFTR: $BADCLUS is specific for NTFS. However SD cards are usually not
> formatted using NTFS. But FAT and ExFAT also have mechanisms to record
> bad blocks which should not be used any longer.

If a flash media (usb stick, card) does have a bad sector I don't see 
why not marking it as bad in the filesystem. Of course, you can decide 
to garbage the thing as soon as. Those devices do not have bad sector 
management in firmware.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#2642

On Thu, 10/24/2024 1:20 PM, ...winston wrote:
> Carlos E.R. wrote:
>> On 2024-10-24 09:20, Paul wrote:
>>> On Wed, 10/23/2024 5:54 PM, Andrews wrote:
>>>> I need a bigger sd card - I spent years for this moment by using Windows to
>>>> make Android sdcard swaps smoother and drama reduced experiences for all.
>>>>
>>>> Some questions...
>>>> Does a Windows "Quick Format" work as well as the slow format?
>>>> Does the format type matter when the sd card is to be used in a phone?
>>>> Do you change the volume label when you format on Windows for Android?
>>>> <https://i.postimg.cc/dVtqQ9dX/sd01.jpg>
>>>>
>>>> Some background...
>>
>> ...
>>
>>>> Did I need that slow format?
>>>> Is the default of XFat (128kbyte allocation unit) an OK setting for phones?
>>>> Is the type of card I bought OK for phones?
>>>> The (slow) format is still running, but when it's done, I'm going to copy
>>>> my "0001" data over from the old sdcard in the phone, to the new sdcard.
>>>>
>>>> And then I'm going to swap out the old sdcard for the new one for, what I
>>>> hope to be a seamless experience using Windows to make Android smoother.
>>>>
>>>> Wish me luck!
>>>
>>> You would buy an SD card with static and dynamic wear leveling.
>>>
>>> A quick format is good enough. It writes and puts a FAT or $MFT on the partition.
>>>
>>> The slow format does the same, except it includes a read-verify of the surface.
>>
>> Doesn't it fill everything with zeroes as well? Or erase all sectors? That reduces the life of the card or stick.
>> Writing zeros for full format option was introduced with Vista. 
> Applicable also to all later Windows o/s.
> Full format
>  - files erased
>  - writes zeros to the whole disk
>  - drive scanned for bad sectors(does not fix bad sectors)
>  - new root directory and file system

I recommend using Process Monitor, to track what a tool does to a device.

USB is a bit of a problem, as it is treated differently.

Not everything is logged on the system, with the same skill and dexterity.
You won't know whats going to happen until you get there.

*******

A full format was a concept of a long time ago. It might have been
called a Low Level Format.

Devices could be soft sectored. There was an index mark on the drive.
As the drive would rotate, your LLF would lay down a track. This
includes writing header section, write splice, and payload area.
If you stopped the low level format, the drive was bricked.
And seeing as the drives cost $1500 back then, you looked
like a right dope when this happened. (At least once, the power
went off at work while I was doing that.)

well, modern drives are no longer soft sectored. We no longer redefine
the interleave pattern by rewriting the entire surface of the platter.

Modern drives have servo wedges, and both headers and servo wedges are permanent.
The header is the address.

The only thing you can do to a modern drive, is write the payload section
of a sector.

Now, flash drives, the address is implicit. The address is hard wired.
Via a MAP table, there can be a mapping between external virtual LBA
and internal storage LBA. The written part of the flash, contains
the 512 byte sector, plus a 50 byte syndrome with Reed Solomon code in
it. I have never seen any information which points to there being
a verification LBA value in the sector too. But the size of the sectors
does not have to be a precise power of two. Nothing inside modern flash
has to be like that any more. They use all sorts of weird numbers for
stuff, and I don't know the rule set for that.

When you format a drive, the activity does the bare minimum.
You rewrite the metadata tables. Most of them, placing a
minimal length table is sufficient (the table will grow with time).
The master file table, it will be small, and it will have all file
entries removed.

None of the remaining clusters, need be written. The OS is not
a maintainer of a forensic situation. The user must know where the
information leakage points are, and use the right tool for the job
when highest security is required. I have tested this, by injecting
test patterns on drives, and finding later, two hundred "shards"
of info were left behind. Naturally, this leaves me just a bit concerned
about my control of things.

   diskpart   clean      # Remove partition table, hardly cleans a damn thing, takes one second
              clean all  # Takes hours on a slow drive, overwrites the surface with zeros

   dd.exe                # dd if=/dev/zero of=/dev/sda bs=8192
                         # That writes zeros over the storage device SDA.
                         # Hard drives a divisible by 8192. The entire surface is written.
                         # Consult the help, to determine the real name string of the drive.
                         # The name shown is just an illustration.

You can then partition and format, in the knowledge that any "format"
command you're using, which does not do a lot, all the other clusters
are already zero because you dd'ed them and you don't have to worry
about information leakage.

Any time I do research on disk layouts, I establish a background pattern
by zeroing the entire drive. This takes a few hours on the size of drive
I would normally use. Next, I partition the drive. Then, take a hex editor,
and "scroll" down near the end of the disk. The GPT secondary table stands
out like a sore thumb, down at the end of the drive. You can't miss it then,
because most of the drive is still zeroed.

Similarly, for RAID research, I zero the drive on an alternate-brand
computer, do the RAID setup on the branded RAID I want to test, then
bring the drive back to the alternate-brand computer and "scroll" with
my Hex editor. Then I can see the 64KB or smaller RAID metadata table.

By knowing how these things work, you can be in control.

Using tools like Process Monitor, you can observe things being done,
if need be.

   Paul

[toc] | [prev] | [next] | [standalone]

#2645

Paul wrote:
> On Thu, 10/24/2024 1:20 PM, ...winston wrote:
>> Full format
>>   - files erased
>>   - writes zeros to the whole disk
>>   - drive scanned for bad sectors(does not fix bad sectors)
>>   - new root directory and file system
> 
> I recommend using Process Monitor, to track what a tool does to a device.
> 
> 
> A full format was a concept of a long time ago. It might have been
> called a Low Level Format.
>  
>     Paul
> 

Iirc, a true Low Level format required 3rdparty tools.
  The last time I did a low level was years ago a Connor(Seagate 
manufactured drive(small drive ~500 MB) installed in a HP tower.
Don't even remember the tool, obtained it from an IT admin on a 3.5" floppy.
  - a few months later, the drive died. Track O, un-repairable.

<https://www.easeus.com/partition-master/high-level-format-vs-low-level-format.html?>

<https://www.easeus.com/computer-instruction/low-level-format-vs-standard-format.html?>

<https://www.minitool.com/partition-disk/high-level-format-vs-low-level.html>



-- 
...w¡ñ§±¤ñ

[toc] | [prev] | [next] | [standalone]

#2646

On Thu, 10/24/2024 9:13 PM, ...winston wrote:
> Paul wrote:
>> On Thu, 10/24/2024 1:20 PM, ...winston wrote:
>>> Full format
>>>   - files erased
>>>   - writes zeros to the whole disk
>>>   - drive scanned for bad sectors(does not fix bad sectors)
>>>   - new root directory and file system
>>
>> I recommend using Process Monitor, to track what a tool does to a device.
>>
>>
>> A full format was a concept of a long time ago. It might have been
>> called a Low Level Format.
>>  
>>     Paul
>>
> 
> Iirc, a true Low Level format required 3rdparty tools.
>  The last time I did a low level was years ago a Connor(Seagate manufactured drive(small drive ~500 MB) installed in a HP tower.
> Don't even remember the tool, obtained it from an IT admin on a 3.5" floppy.
>  - a few months later, the drive died. Track O, un-repairable.
> 
> <https://www.easeus.com/partition-master/high-level-format-vs-low-level-format.html?>
> 
> <https://www.easeus.com/computer-instruction/low-level-format-vs-standard-format.html?>
> 
> <https://www.minitool.com/partition-disk/high-level-format-vs-low-level.html>

I was doing them on 5MB and 10MB (full height) drives coming into the department.
It's possible a SASI controller was part of the solution at the time.
And you had to look out the window and check the weather before
you started (some of our power drops were weather-related). And you had
to have the operation run to completion, or the drive would be bricked.

One of the reasons for doing an LLF, was the change from interleave 3 to
interleave 1. Something was "going fast enough" on our hardware setup,
we could change the interleave. (It might have even involved a different
brand SASI card.) While that should have made the drive feel faster, considering
how creaky everything was back then, you would hardly notice.

       1 4 7 2 5 8 3 6 9   Interleave 3  (takes three rotations to read nine sectors)
       1 2 3 4 5 6 7 8 9   Interleave 1  (one rotation to read nine sectors)

The data rates were awful (less than 1MB/sec) ... but nobody benched anything back then.
We didn't want to know :-) When the alternative was a floppy drive at 75KB/sec,
you were not complaining, no matter what the number was.

Before hard drives came along, a "dream machine" was one with two floppy drives.
While this isn't ours, it illustrates what people used to fight over. Nobody
wanted the machines that had only the one floppy (your *OS* was on that floppy).
Any time the OS floppy comes out of the machine, your screen would say
"Hey, dumbass, put my floppy back in" :-) Being asked to copy a data floppy,
would always bring a scowl to the face of a single floppy drive computer user.
I had one of those for a while. There was so little RAM in the computer,
you couldn't buffer a full floppy in there! Nightmare stuff.
"Insert floppy 1" "Insert floppy 2" "Insert floppy 1" ... "Hey dumbass..."

https://www.hpmuseum.net/images/9895A-35.jpg

   Paul

[toc] | [prev] | [next] | [standalone]

#2647

Paul <nospam@needed.invalid> wrote:
[...]

> Before hard drives came along, a "dream machine" was one with two
> floppy drives.
> While this isn't ours, it illustrates what people used to fight over.
> Nobody wanted the machines that had only the one floppy (your *OS* was
> on that floppy).
> Any time the OS floppy comes out of the machine, your screen would say
> "Hey, dumbass, put my floppy back in" :-) Being asked to copy a data
> floppy, would always bring a scowl to the face of a single floppy
> drive computer user.  I had one of those for a while. There was so
> little RAM in the computer, you couldn't buffer a full floppy in
> there! Nightmare stuff.  "Insert floppy 1" "Insert floppy 2" "Insert
> floppy 1" ... "Hey dumbass..."
> 
> https://www.hpmuseum.net/images/9895A-35.jpg

  Two 8" floppy drives for a mere $5830! A steal!

<https://www.hpmuseum.net/display_item.php?hw=262>

  Thanks for the memory! I enjoyed the 'Collector's Notes' and the
reference to <https://www.hp9845.net/9845/projects/hpdrive/>. The things
people do to keep old stuff working. Amazing!

[toc] | [prev] | [next] | [standalone]

#2648

On 2024-10-25 07:35, Paul wrote:
> Before hard drives came along, a "dream machine" was one with two floppy drives.

Yes. I could not afford a hard disk (didn't sufficiently know what it 
was, anyway), but I knew I needed two floppy drives on my first machine.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#2649

On Fri, 10/25/2024 9:11 AM, Carlos E.R. wrote:
> On 2024-10-25 07:35, Paul wrote:
>> Before hard drives came along, a "dream machine" was one with two floppy drives.
> 
> Yes. I could not afford a hard disk (didn't sufficiently know what it was, anyway), but I knew I needed two floppy drives on my first machine.
> 

We originally started with hard drives, for departmental server level.
The cost could be spread over more desks that way.

Then the 3 inch high "chunks" of hard drives arrived (and the opportunity
to put one on each desktop had finally arrived). They
could be smaller than other equipment we'd worked on or evaluated.
But still the things struck you as "not very elegant" and
little better than "a floppy with a rigid platter". Just the
heads moving radially, and using a stepper motor to move in and
out, that wasn't elegant, when twenty feet away was equipment
using voice coil. It's not like the consumer technology at the time was
aggressive.

And that stuff could be flaky. My initial reaction was not to take
one home with me :-) It would be a small bundle of trouble. If
you didn't have one, that's a good thing. The shock or vibration spec
was only about 2G's or so. Jumping on the floor could crash the heads.

The departmental server, the heads retracted out of the disc pack. The
heads didn't touch the platter when the drive was not in usage. Whereas the
Seagate full height drive was CSS (contact start stop). And I don't think
there was any retraction attempt -- if the power goes off, the heads
would just drop onto the platter where they were.

Not really all that attractive, for $1500 . Plus the cost of the controller card.
The drive itself was as dumb as a floppy. No SMART. SMART did not exist then.
And Enhanced Secure Erase, consisted of dropping the drive on the floor.
No, we didn't drop any. But the first year, there might have been four failures.

And there was no email on there. Our email was on mainframes. Developer source
was stored on the departmental server. This meant, at least initially, the
risk factors on the hard drive were minimal. I filled mine up with files,
but it took two years of usage, to fill a 10MB drive. Our file systems guy had
collected statistics, and the average file size back then was 2KB. And that's partly
because there were no graphics. Yet, we still did desktop publishing. The user
manuals were two feet thick.

   Paul

[toc] | [prev] | [next] | [standalone]

#2650 — Olde Disk Drives (was: Re: Using Windows to make Android smoother

On Fri, 25 Oct 2024 11:02:42 -0400
Paul <nospam@needed.invalid> wrote:

> On Fri, 10/25/2024 9:11 AM, Carlos E.R. wrote:
> > On 2024-10-25 07:35, Paul wrote:
> >> Before hard drives came along, a "dream machine" was one with two floppy drives.
> > 
> > Yes. I could not afford a hard disk (didn't sufficiently know what it was, anyway), but I knew I needed two floppy drives on my first machine.
> > 
> 
> We originally started with hard drives, for departmental server level.
> The cost could be spread over more desks that way.
> 
> Then the 3 inch high "chunks" of hard drives arrived (and the opportunity
> to put one on each desktop had finally arrived). They
> could be smaller than other equipment we'd worked on or evaluated.
> But still the things struck you as "not very elegant" and
> little better than "a floppy with a rigid platter". Just the
> heads moving radially, and using a stepper motor to move in and
> out, that wasn't elegant, when twenty feet away was equipment
> using voice coil. It's not like the consumer technology at the time was
> aggressive.
> 
> And that stuff could be flaky. My initial reaction was not to take
> one home with me :-) It would be a small bundle of trouble. If
> you didn't have one, that's a good thing. The shock or vibration spec
> was only about 2G's or so. Jumping on the floor could crash the heads.
> 
> The departmental server, the heads retracted out of the disc pack. The
> heads didn't touch the platter when the drive was not in usage. Whereas the
> Seagate full height drive was CSS (contact start stop). And I don't think
> there was any retraction attempt -- if the power goes off, the heads
> would just drop onto the platter where they were.
> 
> Not really all that attractive, for $1500 . Plus the cost of the controller card.
> The drive itself was as dumb as a floppy. No SMART. SMART did not exist then.
> And Enhanced Secure Erase, consisted of dropping the drive on the floor.
> No, we didn't drop any. But the first year, there might have been four failures.
> 
> And there was no email on there. Our email was on mainframes. Developer source
> was stored on the departmental server. This meant, at least initially, the
> risk factors on the hard drive were minimal. I filled mine up with files,
> but it took two years of usage, to fill a 10MB drive. Our file systems guy had
> collected statistics, and the average file size back then was 2KB. And that's partly
> because there were no graphics. Yet, we still did desktop publishing. The user
> manuals were two feet thick.
> 
>    Paul

A great place for this nostalgia is afc; note the xpost.
I imagine followup replies would be best directed there, i.e. dropping the
xposts back to acow-10 and acmw.

-- 
Bah, and indeed Humbug.

[toc] | [prev] | [next] | [standalone]

#2637

Paul wrote on Thu, 24 Oct 2024 03:20:49 -0400 :

> You would buy an SD card with static and dynamic wear leveling.

Hi Paul,
Thanks for that advice. I don't even know what that means. 
On Amazon, they don't tell you that in the product information.
My choices were Lexar or Sandisk. I chose the (cheaper) Lexar.

But should I of given that I need "wear leveling" for that card???

Putting my glasses on & my magnifying glass to the package, I still can
barely read the print - and it's too wide for the macro lens to snap a
single photo of, so I'll create a mosaic with the macro so you can see all
the fine print and funny-looking sdcard-specific-emoji (sdoji?).

 
> A quick format is good enough. 
> It writes and puts a FAT or $MFT on the partition.

Thank you for that advice that a quick format is good enough.
The slow format took a very long time - maybe 45 minutes or so.
The quick format didn't take more than ten seconds (I didn't time them).

> The slow format does the same, except it includes a read-verify of the surface.

Hmm. My slow format gave no "errors", so does that mean there were no read
errors or does that mean any read errors were jumped over by the format?
 
> To "erase" a storage device, diskpart "clean all" will write the entire
> surface with zeros. Or dd.exe can write the surface with zeros.
> 
> It's hard to get good info about SD, like the wear leveling scheme.
> If it has both static and dynamic wear leveling, it could last longer
> because then you can't really burn a hole in it as easily.

Ah. I see. I said so already at the top of this message, unless there's
something in all that sdcard emoji or the super-fine really fine print.

> The difference to a USB flash stick, could be the binning of the flash.
> Maybe the flash is a bit better. USB sticks could be pretty low quality.
> Like purchasing a 16GB USB key, could be a 32GB chip with half of it
> pinned off because it didn't pass.

Well, that original 64GB sd card has on it "Samsung", "EVO", a "3" inside
of a "U", and then "Micro XD" & "SC" & "I" also, which doesn't tell me
offhand if that has the requisite wear leveling but it lasted since May of
2021 in three phones without any indication to me of flash card errors.

> SD has limits on both write speed and read speed. The physical interface
> is pretty "thin", and that's why it can't read faster than it does.

Good information to know, where I use my "/storage/0000-0001/0001/" folder
to store pictures, videos, text files, PDFs, nova homescreen backups, APK
backups, etc., all of which seem "fast enough" for what I am doing.
 
> There is a promise that coming SD cards will have one lane PCI Express
> interfaces, which should make then read better. But when that is done,
> the writing won't be faster. Just as the worse USB3 flash sticks might be
> 100MB/sec read and 10MB/sec write. My Rally2 can write at about 16MB/sec,
> but it doesn't read in a big hurry. Whereas USB3 sticks can have larger
> differences between read and write. And some USB, have "uneven" behavior.
> I've got a stick here now, it stalls for a while, it does a tiny bit of
> writes, then stalls some more. My SD doesn't do that.

I think everyone should have an sd card in their phone because it allows
them to pay for smaller internal storage - and the sd card is portable
(which isn't the same thing as expandable - so let's be clear on that).

Portable means you can pop it out of one phone to use in another phone.
And it all just works - where the sd card - if they format it on Windows to
the same volume name - can be easily swapped out of one working phone into
another working phone and there will generally be no hiccups doing this.

So far my swap out worked as far as I can tell, with all my map navigation
data on the sd card reading perfectly from the map programs (like OSMAnd~)
residing on the phone's internal storage because the phone only knows that
the map data is stored in "/storage/0000-0001/0001/map/osm/." and to the
phone the new card has exactly the same address once I copied it over using
Windows to do that copy (most people use the Internet - but I do not!).

Another question I have is that I've chosen those 8 (actually 9) characters
because every sd card seems to come with that kind of a volume label (e.g.,
BF3A-D4C2); but I wonder if I can format it to one character?

I guess I'll try that since I doubt anyone knows if a volume label of a
single character will work on Android - so I'll run that test separately on
the remaining sd cards as I've already copied over 0001 data to this one.

Would formatting a micro-sd volume label to just "SD" for example, work?

[toc] | [prev] | [next] | [standalone]

#2644

On Thu, 10/24/2024 1:15 PM, Andrews wrote:
> Paul wrote on Thu, 24 Oct 2024 03:20:49 -0400 :
> 
>> You would buy an SD card with static and dynamic wear leveling.
> 
> Hi Paul,
> Thanks for that advice. I don't even know what that means. On Amazon, they don't tell you that in the product information.
> My choices were Lexar or Sandisk. I chose the (cheaper) Lexar.
> 
> But should I of given that I need "wear leveling" for that card???
> 
> Putting my glasses on & my magnifying glass to the package, I still can
> barely read the print - and it's too wide for the macro lens to snap a
> single photo of, so I'll create a mosaic with the macro so you can see all
> the fine print and funny-looking sdcard-specific-emoji (sdoji?).

The information is hard to get.

The Tech Support at the SD company, are mostly clueless.

When an SD has both static and dynamic wear leveling, it
then had the endurance of a SATA SSD drive. You get 600 writes
to every location on the device. The wear is evened out.

A USB flash stick, some seem to have nothing. A few too many
writes to low addresses, and you burn right through it. This
means at USB flash stick death, location 0 has 600 writes
while location 0xFFFFFFFF has zero writes. As does 0xFFFFFFFE.
Much of the upper media section of the device is still
waiting for the first write. And in reality, as near as I
can determine, you're not even getting 600 writes. It's a
pathetic lower number. This happens for TLC or QLC flash,
while the MLC or SLC we can no longer get, that lasts a lot longer.

For any device, we would like that feature. There is a Patriot
(and there are other brands) of USB stick that have an SSD inside
and a USB to SATA adapter chip. And those have both features
and support TRIM.

While some discussion threads, attempt to discuss which
limited model numbers of Sd devices have the feature, there is
no one to verify the info and tell us what we're buying.

This is why I quick format, plug in, and carry on with life.
because I'm not going to find anyone with the answer.

Do backups every once in a while.

   Paul

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.comp.microsoft.windows

csiph-web