Project

General

Profile

Actions

Bug #4814

closed

read-only to read-write mount very slow on nanobsd with slow flash media

Added by Chris Buechler almost 9 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Category:
Operating System
Target version:
Start date:
07/03/2015
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2.3
Affected Architecture:

Description

Opening a new issue to track the regression of old bug #2401. The ro->rw mount is so slow on some hardware that it makes things unusable. Also causes a variety of package reinstall failures. Related comments in #4803, and here:
https://forum.pfsense.org/index.php?topic=95938.msg533908#msg533908
among other places.

Actions #1

Updated by Chris Buechler almost 9 years ago

this patch fixes the issue, though apparently isn't good.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176169

We've never seen it cause any problems though in years of usage, so bringing it back for nano might be a stop gap measure.

Actions #2

Updated by Jim Thompson almost 9 years ago

  • Priority changed from High to Normal

that patch isn't going into pfSense.

We'll investigate 'why' the transition is slow, then attempt to develop a solution.

But this patch is not that solution.

Reduced priority to 'normal'.

Actions #3

Updated by ky41083 - almost 9 years ago

Alignment discussed at great length here https://forum.pfsense.org/index.php?topic=95938.0

doktornotor's input can be safely ignored. Not only because it's wrong, but because dumb.

Actions #4

Updated by ky41083 - almost 9 years ago

Can we safely assume that proper image alignment with slower flash devices that are having issues, will at least help the remount issue a bit?

Or should fixing image alignment be opened as a separate bug all together?

Actions #5

Updated by Phillip Davis almost 9 years ago

I have watched the back-and-forth on that thread and restrained myself from commenting. Keith, I will be surprised if you are not correct. Putting the start of something on-"disk" at 512-byte-block number 63 (referenced from a start block of 0) just seems odd, specially if that something is writing to "disk" in chunks bigger than 512-bytes. Obviously it depends on the workings of the underlying FreeBSD driver and then the firmware in the CF card "disk". I can't believe it could do any harm to start at 64 instead of 63, so would be worth trying and testing.

Of course that might be a bit significant a change for 2.2.4, and also needs thinking about how the change can be made during upgrade on existing CF cards, which is something that really would need good testing to make sure not to have any chance of making a system unbootable.

But I think there are enough nanoBSD systems out there that can potentially benefit that it is worth doing some research/development/testing.

Actions #6

Updated by Jim Thompson almost 9 years ago

But I think there are enough nanoBSD systems out there that can potentially benefit that it is worth doing some research/development/testing.

Keith & Phil,

Feel free to research and report back. No doubt some improvement is possible, but I don't think that cyl 64 is the answer.

nor do I think that moving the start of the filesystem is going to be easy.

Actions #7

Updated by Jim Thompson almost 9 years ago

  • Assignee set to Chris Buechler
Actions #8

Updated by Chris Buechler almost 9 years ago

  • Subject changed from read-only to read-write mount very slow on nanobsd to read-only to read-write mount very slow on nanobsd with slow flash media
  • Status changed from Confirmed to Closed

Updated subject to reflect the root of the issue. Of a whole stack of various CF and SD cards I have here, there is only one make and model of each made in the past ~7 years that's affected. We're not putting the forcesync patch back in, as it's dangerous. Those who are affected can either use better flash, or stay permanent rw mounted (which has been confirmed to survive upwards of 1000 power cycles each on ALIX and APU on slowest flash I could find).

The alignment may or may not be an issue, research and results welcome, but is a separate issue entirely.

Actions #9

Updated by ky41083 - almost 9 years ago

Chris, I'm not sure if you are referring to the alignment issue or the remount issue only effecting 1 of the CF / SD cards you tested. Can you comment for clarity?

Also, I have research & references, all real world, both general and FreeBSD specific. They are in a later post, linked to at the bottom of the OP of the above thread. Should I post them here, or start a new bug and post them there?

I also think I have it worked out how to treat existing installs, there may possibly be only one good way to handle them.

Actions #10

Updated by Phillip Davis almost 9 years ago

I am happy with the way it is now for 2.2.4. At least it is reliable, even if the speed varies on different cards of different brand/age/whatever other factor.
Keith, I suggest you open a new ToDo to investigate the possibilities of partition block alignment and its benefits. If you have some ways to adjust existing installs and/or a build method to align the partitions... then let me know. I am happy to test on my spare systems/CF cards. And also check on the APU with SD card to make sure nothing goes wrong there either.

Actions #11

Updated by Chris Buechler almost 9 years ago

all my comments were re: rw->ro mount time.

Keith, Phil's suggestion to open a todo including those references is a good idea. Not something we're going to get into in a maintenance release.

Actions #12

Updated by ky41083 - almost 9 years ago

Actions

Also available in: Atom PDF