Page 1 of 1
Forum

Welcome to the Tweaking4All community forums!
When participating, please keep the Forum Rules in mind!

Topics for particular software or systems: Start your topic link with the name of the application or system.
For example “MacOS X – Your question“, or “MS Word – Your Tip or Trick“.

Please note that switching to another language when reading a post will not bring you to the same post, in Dutch, as there is no translation for that post!



Share:
Notifications
Clear all

[Solved] Monterey brought to its knees by resize2fs

10 Posts
2 Users
0 Likes
724 Views
(@Anonymous)
Joined: 1 second ago
Posts: 0
Topic starter  

Hi. As requested, I'm following up on our recent discussion here in the forum.

I re-ran the test, only this time sourcing from a flash drive instead of my SSD, and the problem did not occur. Either (a) the speed of the flash drive being less than my SSD resulted in less of a bottleneck, or (b) my SSD not being involved in the process allowed it to continue serving operating system demands. Given that CPU is not a bottleneck here, I'm going with (b).

APB "stops responding" during the resize2fs run in both cases; but in this latest test, the rest of the operating system is continuing to run normally.

Is there any way to throttle resize2fs? If not, I'm thinking the problem is insoluble.

Also, shouldn't APB continue to "respond" during the resize2fs execution?

Incidentally, the APB window shows "10:57 - Expanding Linux partition" and "restore progress 100%" and "Expect completion at 10:58". It is now 11:06...

Activity Monitor shows resize2fs having thus far written only 5GB of the expected 30GB "expanded filesystem file". Not surprising, considering I'm running it on a flash card, but....."restore progress 100%"? Hardly!

It's also worth noting that clicking "abort" does nothing. Running `kill -9` on resize2fs also does nothing. I had to physically yank the flash card to get it to stop, resulting in an Access Violation in APB.

Screenshot


   
ReplyQuote
 Hans
(@hans)
Famed Member Admin
Joined: 11 years ago
Posts: 2660
 

Excellent test to run from your flash drive - well done. 👍 
But we still see something very weird going on. It makes it even weirder that you're the only one reporting this issue.
Obviously this doesn't mean you're the only one experiencing this, but it does tell me that it's quite uncommon.
Lets' see what we can do to get this fixed. 

Your system not freezing when doing the test from an external flash drive most certainly points to your SSD not being involved in the process. Under different circumstances I'd guess your system is very heavily swapping memory data on your disk. This however would make no sense since you have 16Gb of RAM, and one would think an SSD would not be all that terrible even if it would swap a lot.

The additional odd behavior, like APB freezing, not reaching 100%, etc, I'll take as a side effect of somehow things freezing up on your computer (for now). The entire resize2fs call is done straight from APB, so that's why APB is going bonkers as well. 

Once more: There is no way that I can throttle resize2fs.
It's a Linux tool that I compiled for macOS, and it is not developed by me.
Running a command like that doesn't allow me to throttle its CPU usage either. It just runs when called upon.

Should look something like this:

/Applications/ApplePiBaker.app/Contents/MacOS/resize2fs -M /path/to/extracted_linux_partition_file 30478958592

(if I recall correctly, and the size is based on your screenshot)

 

I did some online searching and couldn't find any reports of resize2fs freezing up a system. However, resize2fs is a Linux tool, and can only be used on an Linux Ext partitions - which would be tricky to test on a Mac (this is why APB extracts the Ext partition to a separate file).

Maybe we can try something else on your SSD that may be "intense" - but we kind-a already concluded the task isn't disk or CPU intense at all.

 

Can you tell me what kind of Mac model do you have?
So far I only know that you're running Monterey, have 16Gb RAM and a 1Tb SSD.
What kind of CPU? (Intel or M1/M2 Apple Silicon)
What kind of SSD? (SATA, M2, embedded like with Apple Silicon, brand/model?)

 

I've done some testing on the following devices, and cannot reproduce this at all - which sucks of course and makes debugging difficult.

- Mac Pro (2013 trashcan, 12 core Xeon, 64Gb RAM, 1Tb SSD, Monterey)
- 15" Macbook pro (2016, 4 core i7, 16Gb RAM, 512Gb SSD, Monterey)
- 12" Macbook (2016, 2 core 1.3GHz Intel Core M, 8Gb RAM, 256Gb SSD, Ventura, very slow but system remains very responsive)
- 16" Macbook pro (2021, M1 Max, 32Gb RAM, 512Gb SSD, Ventura) 

 

p.s. Just for completeness, posting the image here (as a new user it takes 5 approved posts before you can attach images and such - its a silly spam protection of the forum);


   
ReplyQuote
(@Anonymous)
Joined: 1 second ago
Posts: 0
Topic starter  

The System Information tool reports the following specs:

Model Name: Mac mini
Model Identifier: Macmini7,1
Processor Name: Dual-Core Intel Core i7
Processor Speed: 3 GHz
Number of Processors: 1
Total Number of Cores: 2

The SSD is a brand new one that I fitted a couple of weeks ago. It's a 1TB Patriot P210.

Before fitting it, I tested the capacity using a tool that fills up the disk with large files and then verifies them, to check that the drive is really the size claimed, and not a fake. I also benchmarked the SSD with CrystalDiskMark, but I didn't keep a record of the result.

I will try to find some Mac software to do a benchmark on the drive.

Should I try to run resize2fs "manually" and see if the problem occurs?


   
ReplyQuote
 Hans
(@hans)
Famed Member Admin
Joined: 11 years ago
Posts: 2660
 

With these specs I wouldn't right away expect great performance, since the CPU an old dual core i7 from 2014.
I wouldn't expect this kind of slowdown either though, and you didn't observe a CPU spike either.

Running resize2fs manually would be a little bit tricky, since you'd have to extract the linux partition manually - or ... run the backup with resize option and copy the extracted partition. The latter would be quite a feat considering your system comes to an almost screeching halt.
Also, from what you told me, this only happens when using the resize option, and killing the resize2fs task frees up the system again.
So I'm not sure a manual run would teach us anything new.

Having said that: your SSD tests is a pretty good indicator that the SSD is OK.
Add to that: no CPU spike, and not running out of memory (16Gb).

I'm really baffled. What else is running on your system?


   
ReplyQuote
(@Anonymous)
Joined: 1 second ago
Posts: 0
Topic starter  

I think the important fact to keep in mind here is that I was running APB perfectly fine on El Crapitan for years. I update to Monterey and suddenly it can't cope.

It's gotta be something to do with either Monterey or the SSD. Those are the only things that changed. Although I'm also running a newer version of APB now.

(Monterey refused to install to my original SSD because "it's wearing out")

I'm running VMWare, Chrome, Thunderbird, Telegram, Discord.....and a bunch of small utilities. But (aside from VMWare) this isn't important because I was running them on El Crapitan and APB worked fine.

You say you can't throttle resize2fs because it's not your software. But you also say you "compiled it for MacOS". Therefore you have the source, and could presumably insert the Mac equivalent of a sleep() call somewhere and recompile, surely...?

Can you maybe send me the resize2fs source, and I'll have a go?


   
ReplyQuote
 Hans
(@hans)
Famed Member Admin
Joined: 11 years ago
Posts: 2660
 

You do make an excellent point there - assuming you used APB with the resizing on El Capitan as well.

The version of APB you ran under El Capitan had the resize option as well right? And with resize option it did run just fine.
Just making sure since v1, and early v2 versions, did not have this option, and your current APB runs fine without resizing.

 

As for running other apps; I was more thinking of anything that runs while you're using APB.
Like in the menubar. For example; I'd assume you would not run VMWare while doing a backup with APB.
And yes; your statement is here valid indeed again, that when it ran just fine on El Capitan, then why is it a problem now ...

I was just wondering how many threads is your activity monitor showing when running APB with resize (when slowdown kicks in)? (apologies if you already answered that before)

 

When comparing El Capitan to Monterey, then I would say that there are quite a few significant changes in the OS (you skipped 5 major OS updates). The most important change(s) being how Apple is restricting a lot of things, or making it very difficult to do (like reading or writing an entire disk).

 

As for throttling; Suggestions and ideas are always very welcome, and I by no means want to be difficult, stubborn, or anything like that, but adding sleep statements would be a bad idea for numerous reasons.

  1. Adding sleep statements in code is a bad practice to begin with.
    In event driven operating systems, these calls should very rarely be used or needed.
    Kind-a like the good old "goto" statement in BASIC back in the day 😉 
  2. It would also take quite a lot of time to implement - one would need to study the source (you can find the source code here as a part of e2fsprogs) to determine what "good" locations there would be. (there really are no good locations - but feel free to try!)
  3. Additionally, at best this would address the symptoms, if it even works, and not the real cause of this issue.
    Personally I prefer to put effort in fixing what is causing this slowdown, and not "cover up" the symptoms. So you may run into the same issue again, potentially, with another application.
  4. And finally: It would affect all other APB users negatively - their resize would now slow down noticeable, just because your system is experiencing an issue. Which would not be fair to them, and very much undesirable in general (we want things to go as fast as possible right?). Or ... I would have to start to maintain two versions ... one with and one without throttle option. Something I'm not very eager about either.

 

 

Something you could try:

1. Make a backup of your SD card to an IMG file WITHOUT resizing. It has to be an IMG file, so no resizing and no compression like ZIP etc.
2. When done, double click the IMG file - if asked open with 'Disk Mounter'.  The disk should be mounted, but you may not be able to see the content of the Linux partition (macOS does not natively support the Ext filesystem).
3. In APB, you can now select the mounted disk (IMG), enable the resize option, and make a backup. (should be very fast)

Timewise this should take about the same time in total, but maybe it works better for your system. Worth a try, and may not work out as hoped for.

Note: during the backup in step 3, you may see a file appear with "linuxpartition" in the name - that would be the Ext partition needed for resize2fs. This trick may fail though.


   
ReplyQuote
(@Anonymous)
Joined: 1 second ago
Posts: 0
Topic starter  

I benchmarked my SSD, in case it's important.

Yes, the old version had resize. I will try the old version, see if it causes the same problem. Although of course I'm very reluctant to actually run APB tests, because then I can't get any work done for potentially hours. The slowdown is literally so severe that even typing text into a document is impossible. (And it's almost impossible to kill resize2fs – due to system chug, and also due to resize2fs completely ignoring "kill -9"!!! – and it sometimes hard-crashes the entire operating system when I do!)

I do use VMWare while performing a backup, as I get a lot of my work done in there. Or at least, I try to. I guess I could close VMWare and see if the problem still happens. Maybe when I'm finished working tonight.

I will check how many threads. Do you mean "how many APB is using"?

By "sleep statement", I meant like the Windows sleep() call, which yields to other processes for a specific number of milliseconds. It's fine to use in a multitasking environment.

Seeing as how the bottleneck seems to be with the SSD (or the operating system itself?) I doubt that imaging first and then resizing would help. But I will try it. (See above about the impact of tests on my productivity, however.)

(I wonder if my wife's ancient Macbook would run Monterey, for test purposes. I doubt it. And it'd be slower, and therefore not a fair test...)


   
ReplyQuote
 Hans
(@hans)
Famed Member Admin
Joined: 11 years ago
Posts: 2660
 

I'd be reluctant to test as well -- wouldn't be looking forward to my Mac being occupied or unusable for hours either.

You run VMWare Fusion while doing a backup? Like running a virtual machine? Oh wow, interesting. I guess I never tried it on a dual core i7 while doing a lot of internal disk I/O (resizing a file system). I would most certainly try APB again, and making sure to shut down every single application or tool, especially VMWare. I do use VMware as well, just have a few more cores available, and when doing a backup I try to give APB as much resources as possible so it will run at max speed.

I'd try that before trying anything else.

As for threads: I meant the total number of threads running on your Mac (APB and all other apps/services/etc).

 

On that note: your SSD benchmarks are pretty bad. To give you an idea what my 10 year old SSD does.
Your write speeds are terrible (my 10 year SSD does 10x the speed).

My best guess is that you mac Mini hardware has to work hard to keep up. Something is wrong there.
You have not observed a CPU spike so, so my best guess is that your SATA bus or SSD cannot keep up.

Trying to find answers, I found others experiencing SSD related issues on your model Mc Mini.
Of course I cannot say with certainty if these are relevant for you or not:
- Bad RAM (that would be a real problem, as memory appears to be soldered on the board)
- MacMini7,1 SSD slow discussion on Reddit (all kinds of suggestions there, found some more here as well)
- Needed UEFI update (latest version for you Mac)


   
ReplyQuote
(@Anonymous)
Joined: 1 second ago
Posts: 0
Topic starter  

Meh. It's a cheap SSD. That's probably why it's slow.

But before I upgraded to Monterey, I was APB-resizing to a mechanical drive. Granted it wasn't my OS drive. I reckon resize2fs is just making the SSD (or interface) work flat-out and it doesn't have any spare cycles to service the OS itself. And therefore the machine locks up.

We need a way to throttle resize2fs. Simple as that.


   
ReplyQuote
 Hans
(@hans)
Famed Member Admin
Joined: 11 years ago
Posts: 2660
 

Posted by: @Anonymous

We need a way to throttle resize2fs. Simple as that.

Well, feel free to give it a go ... you can find the source code here as a part of e2fsprogs.
I did the "make" only for resize2fs (resize) and e2fsck (verify filesystem) - which need to be located in:

/Applications/ApplePiBaker.app/Contents/MacOS/

 Still do not a fan, but there is no harm in trying, right? 😊 


   
ReplyQuote
Share: