You could be there a long time...

What in particular makes it more prone to fail in the boot process? I thought the wear would mostly be an issue due to swap file usage, and I'd have thought usage of that is minimal until some RAM hungry apps are open?

Perhaps you could speed up the failure by reducing the system RAM, and Perhaps having the OS launch something on startup that will wear the disk a bit, before it reboots?

Heh nice thread, I'm really interested to see where this goes.
I assume your goal is to simulate a normal usage scenario and reach a conclusion along the lines of "it survived 1000 boot processes and if you factor in the actual usage during these times, this sd probably won't last a year" (or the opposite)?

RetroPCCupboard wrote on 2026-01-23, 14:42:

You could be there a long time...

What in particular makes it more prone to fail in the boot process? I thought the wear would mostly be an issue due to swap file usage, and I'd have thought usage of that is minimal until some RAM hungry apps are open?

Perhaps you could speed up the failure by reducing the system RAM, and Perhaps having the OS launch something on startup that will wear the disk a bit, before it reboots?

XP writes to the registry hives, event log, & NTFS journal ($LogFile) on every reboot, so without wear leveling, those spots will get worn. It also writes to the page file too.

Reducing the ram would increase the use of the page file, but since it's usually cheap and easy and satisfying to add more ram to your retro XP computer, why would you run a XP system without it?

Reboots arent what murders SDcards used this way.

Abusive numbers of tiny writes all over the place does.

Browser caches, temp files from installers, and idiotic/braindead pagefile operations.

THOSE kill SDCards.

[I used a microSD as /home on a hacked chromebook running xubuntu. Firefox was THE major contributor to the first go-around of trying this, as was the syslog, but browser cache was the primary offender. It took about 3 months to die from being used as a daily driver, before I got wise, and instituted mitigations. After doing that, the whole chromebook failed before the microSD did, with several YEARS of service given. Web browser cache is by far and away the most abrasive thing to an SDCard used this way.]

konc wrote on 2026-01-23, 15:42:

Heh nice thread, I'm really interested to see where this goes.
I assume your goal is to simulate a normal usage scenario and reach a conclusion along the lines of "it survived 1000 boot processes and if you factor in the actual usage during these times, this sd probably won't last a year" (or the opposite)?

Some people fret about running solid state storage without wear leveling or trim support, for well known reasons.

I just want to put some numbers around it to gage how worried you should be. 16GB SD with NTFS is probably a worst case scenario.

If it dies after 250 reboots, I think we can all agree that this isn't how you want to build an XP system.

If it makes it to 2500 reboots, then maybe it's not the biggest factor to worry about if you are willing to buy an new SD every 5 years.

wierd_w wrote on 2026-01-23, 19:29:

Reboots arent what murders SDcards used this way. […]
Show full quote

Reboots arent what murders SDcards used this way.

Abusive numbers of tiny writes all over the place does.

Browser caches, temp files from installers, and idiotic/braindead pagefile operations.

THOSE kill SDCards.

Browser cache files? Who uses a web browser on XP on a daily basis in 2026?

Temp files from installers? How often do you install software on an XP build?

Page file? A legit concern, but it will get worked pretty heavily during the reboot process.

I'm not gonna pretend that some bespoke business internal webapp that needs unsafe activeX and IE6 does not still haunt the world in some way, and that some poor schmuck is not left holding the bag looking for an inexpensive alternative to spinning rust. 😁

But for 'ordinary use', like playing vintage vidya gaems, absolutely. SDCard is plenty fast enough (on par with ATA 33 speeds, even at the worst), and should work fine, as long as pagefile is kept off the darn thing.

OK, the great rebootinating has begun!!!

1. 16GB SD card allocated and validated with ValiDrive
2. XP is installed & registered
3. one batchfile added to the startup folder that kicks off a vbscript
4. one VB script created that logs the current reboot count to a text file and then reboots after 20 seconds

Each reboot cycle is taking a second or two less than 1 minute

douglar wrote on 2026-01-23, 21:28:

OK, the great rebootinating has begun!!! […]
Show full quote

OK, the great rebootinating has begun!!!

1. 16GB SD card allocated and validated with ValiDrive
2. XP is installed & registered
3. one batchfile added to the startup folder that kicks off a vbscript
4. one VB script created that logs the current reboot count to a text file and then reboots after 20 seconds

Each reboot cycle is taking a second or two less than 1 minute

Just checking... is the text file being written to a different drive? Would be a shame to lose all the data if\when the card dies.

I am interested to hear how long it lasts though!

I'm hoping that the card is still somewhat readable after failing. If it isn't, I'll put the reboot log on a separate drive.

452 reboots after 7 hours, still going

douglar wrote on 2026-01-24, 04:16:

I'm hoping that the card is still somewhat readable after failing. If it isn't, I'll put the reboot log on a separate drive.

452 reboots after 7 hours, still going

If it were me, the log would be going on a different drive. If the card lasts way longer than you expect and then the file can't be recovered it would be a bit maddening.

I'd just pop in a flash drive and save the log to that.

douglar wrote on 2026-01-23, 19:38:

Browser cache files? Who uses a web browser on XP on a daily basis in 2026?

I'm sure there's at least one on this very forum.

UCyborg wrote on 2026-01-24, 10:31:

douglar wrote on 2026-01-23, 19:38:

Browser cache files? Who uses a web browser on XP on a daily basis in 2026?

I'm sure there's at least one on this very forum.

Ok. Points awarded. I bet you are right. This forum is pretty close to being an “XP Anonymous” meeting. “Hello, my name is Douglar and I’m an XP user.” For that guy who uses XP for daily web browsing, investing in a sata ssd or stock piling old hard drives is probably going to be the best solution. Don’t run your system on a CF or SD.

Update -- 1156 reboots and still going. Setting up a CF D: for the logging file going forward.

I'm testing with 1.25GB of RAM and a generic Windows XP SP3 home install, default everything, TNT2 M64 graphics using the driver that comes with XP.

If I wanted to reduce disk writes without using a 3rd part product:

• Disable System Restore, since it snapshots every boot
• Set the page file to a fixed size, to avoid all the file system tweaks that XP does to a dynamic page file every boot
• Disable prefetch to avoid .pf files in C:\WINDOWS\Prefetch
• Disable NTFS 3.1 "Last Access Timestamp" to avoid the NTFS writes with every access
• Move temp files to a RAM drive. That's pretty self explanatory.
• Disable Automatic updates Service and the Indexing Service. They are always updating.

That would probably reduce the disk writes from ~30MB per boot cycle to about 10MB writes per boot cycle, no?

I could probably reduce it more by:

• Switching to FAT32 to avoid $LogFile journaling
• Switching to Windows 2000

But would that be typical of the casual install ? Maybe.

What I'm really interested in is the "hot spots" to see if the SD does wear leveling or not. XP with NTFS seems like it is pretty good at creating them by default.

Here are some pictures of our Noble warrior that's taking on the SD version of the Kobayashi Maru test

...

douglar wrote on 2026-01-24, 15:51:

If I wanted to reduce disk writes without using a 3rd part product:

[*]Set the page file to a fixed size, to avoid all the file system tweaks that XP does to a dynamic page file every boot

Wouldn't a fixed size page for make even more operations in the exact same area?

2662 reboots, still going strong-- My plan is to keep this going for 100 days.

I guess my 4 year old 16GB consumer card is likely MLC or TLC.
https://www.ssstc.com/knowledge-detail/nand-f … pes-comparison/

• SLC = 100,000 Write Cycles
• MLC = 10,000 Write Cycles
• TLC = 3,000 Write Cycles
• QLC = 1,000 Write Cycles

I think it's safe to say that my SD is not QLC. Or it has wear leveling. Seems that wear leveling might be incorporated into consumer grade flash cards for a while now.

https://forums.sandisk.com/t/which-32gb-micro … -features/35314
the wear leveling feature is supported by all the flash memory devices, so all cards, flash drives and ssds support this feature.

H3nrik V! wrote on Yesterday, 08:05:

Wouldn't a fixed size page for make even more operations in the exact same area?

That's an interesting question. I don't know the answer.

The fixed page file is going to have the contiguously allocated sectors locked in place. The first sector in that block is likely to get worked pretty hard. So that's pretty straight forward.

The dynamic page file is going to grow and shrink each boot, creating more writes. When it grows and shrinks, will it grow and shrink over the same sectors if I am not moving any other files? Will all the file changes intensify the burn on the NTFS $Bitmap records creating a hot spot in a different location?

So it's not exactly clear to me which makes more intense hotspots.

This is going to take a while... full write cycles is most likely somewhere between 8-10k

See here for a person that tested a massive number of SD cards:
https://www.reddit.com/r/homelab/s/VwIab3xD74

douglar wrote on Yesterday, 14:58:

That's an interesting question. I don't know the answer. […]
Show full quote

H3nrik V! wrote on Yesterday, 08:05:

Wouldn't a fixed size page for make even more operations in the exact same area?

That's an interesting question. I don't know the answer.

The fixed page file is going to have the contiguously allocated sectors locked in place. The first sector in that block is likely to get worked pretty hard. So that's pretty straight forward.

The dynamic page file is going to grow and shrink each boot, creating more writes. When it grows and shrinks, will it grow and shrink over the same sectors if I am not moving any other files? Will all the file changes intensify the burn on the NTFS $Bitmap records creating a hot spot in a different location?

So it's not exactly clear to me which makes more intense hotspots.

That's a very valid point. I just always use fixed size swap file (well, at least I did on spinning rust) to minimize fragmentation, thus I was figuring, that it "always" read/wrote on the excact same sectors. But I see your point there.