NanoBSD Image Block Alignment [MisAlignment]
-
Dumb dick question: When you do /etc/rc.conf_mount_rw; /etc/rc.conf_mount_rw the it still takes damn ages without any config changes done and with nothing to write anywhere. How does that fit your write amplification theories? For some mysterious reason still unanswered. ::)
Regards,
Mr. Dumb Dick
A. Because you keep referring to documented referenced facts as theories, like an ignorant dick.
B. Because no one likes teaching ignorant dicks how to use Google.
-
Right. The most amplified writes are those where there's nothign to write. Excellent theory.
-
Right. The most amplified writes are those where there's nothign to write. Excellent theory.
I can't count now, the number of times I've said, remounting UFS results in writes to disk.
Nor can I count, the number of times I've referenced the source of the old kernel patch as hard proof of this.
BTW, the answer was actually…
E: Your Mom
-
Ok, seriously now… the reason I'm taking a minute to post something useful...
If you question the alignment, simply flash a drive with a NanoBSD image, boot Gparted Live from a disc or USB [YUMI works great]. If the storage device with pfSense on it uses 512 byte sector emulation, the very first [only] MBR partition that it can read, will start at sector 63. You can see all of this from the GUI.
If your device with pfSense NanoBSD on it uses a different size for sector emulation, just multiply whatever that sector size is by the sector number the first MBR partition starts on, and you will get 31.5K.
Then, look at the very first [of three] FreeBSD slice inside that first MBR partition, and it starts at sector 0 of the MBR partition, the very same sector that the MBR partition starts on.
-
Oh, fuck me gently sideways. Yeah, it writes even when there's nothing to write.
Look: This shit worked until 8.3. Then someone broke it.
Now, go find the real bug and align your ass instead.
-
Oh, fuck me gently sideways. Yeah, it writes even when there's nothing to write.
Look: This shit worked until 8.3. Then someone broke it.
Now, go find the real bug and align your ass instead.
Sounds like I'm too busy aligning your ass to me…
Anyways, yeah, I've read that thread. They changed some kernel code in 8.3 that added filesystem stability. pfSense devs wrote a patch to unpatch, if you will, 8.3 so it behaved again like 8.2, which the devs currently call an "incorrect" solution, and will not reintroduce that patch. So, forward we go with said bug hunt… ah shit, now you have me giving history lessons.
-
Oh yeah, and, for the… (I can't count how many times now), you're forgetting the whole topic of the thread your posting in. It's not called "fix remount issue" for a reason. That's not what it's about.
It's about fixing the alignment issue, because it is such a dirt simple thing to fix in the build system. Hell, wouldn't fixing it in the installer also make a great upstream patch to get FreeBSD on the same page as every other OS that's still maintained today? I would be infinitely happy if it simply made packages install at a reasonable speed, or made upgrades install at a reasonable speed, or even made slice duplication happen at a reasonable speed.
When I have a CF device that I can write to at (lets round) around 4MB/sec, and after flashing it with pfSense NanoBSD, am now writing to it at 0.04MB/sec, there is clearly some slowdown to be made up there. Even doktornodick or whatever that spells, can't argue against that, not coherently anyways.
-
Bored waiting for Windows to update, added following FreeBSD specific references to articles / threads in the references post:
Edit: FreeBSD Specific References Added
Good Alignment Info for UFS / ZFS on FreeBSD
http://ivoras.net/blog/tree/2011-01-01.freebsd-on-4k-sector-drives.htmlDiscussion about forcing alignment with fdisk, and why it's not updated I suppose (gpart).
https://forums.freebsd.org/threads/gpart-trying-to-force-mbr-partitions-to-be-cylinder-aligned.36439/Awesome example on FreeBSD using an actual drive that reports 4K sectors. This specific example I had not seen before. Remember, our flash drives still report 512 byte sectors, the NanoBSD images will end up aligned to KB or MB boundaries, not specific sectors. And the existing UFS filesystem is already using a 4K fragment size, so the partition is all that's left to fix.
https://forums.freebsd.org/threads/ufs-sector-and-alignment-explanation.42208/This one's for you cmb, for the only reasonable discussion that's taken place here. Thank you for a little sanity.
-
They changed some kernel code in 8.3 that added filesystem stability
ROFL. Look, we added stability. No regression at all. It's not slower than molasses – it's just very stable now!
-
Then find the bug that you are clearly capable of finding, submit it to FreeBSD, and get it patched upstream. pfSense is the wrong place for messy kernel patches.
-
The bug was already filed. Considering people have been complaining just for 3+ years, this definitely can wait. The IPv6 fragmention bug in pf has been filed just ~7 years ago – and of course still well alive and kicking. Welcome to FreeBSD's kernel land, brace for impact!
-
The bug was already filed. Considering people have been complaining just for 3+ years, this definitely can wait. The IPv6 fragmention bug in pf has been filed just ~7 years ago – and of course still well alive and kicking. Welcome to FreeBSD's kernel land, brace for impact!
Hahahaha, epic.
Fragmentation of packets is against the entire IPv6 protocol, for good reason. And you cite the unstable kernel patch as not being applied upstream.
All in the same post.
You absolutely do not belong in this discussion. Any further posts by you will be pertinently ignored by me. If anyone else feels your worthy of a response… never mind, they won't.
-
-
Added info posted in another thread. Also simple testing method found, see end.
What "fixes" the issue? from disk to disk, regardless of type (flash / spinny) and write rate, isn't necessarily the disk controller, but how much cache the disk controller has to work with.
If it has enough cache to absorb all the random writes and spit them out to the physical layer on its own time, it tells the kernel it has all that data, and you don't see hanging issues.
If it doesn't have enough cache to absorb all the random writes, you wait until it has actually written most of it to the physical layer, then it tells the kernel it has all the data, and this is the hang you experience.
So, it's not a disk speed issue at all, it's that faster / larger / newer disks tend to have better controllers with more cache than slower / smaller / older disks.
It doesn't help that NanoBSD images are not 4k aligned, so writes take even longer than they should on flash & 4k drives. Hopefully this gets fixed for the 2.3 branch, or we get a NanoBSD installer so we can fix it manually.
Want to test? Run a pfSense NanoBSD VM on a system with a RAID controller that has a descent size cache in write-back mode. Now try it with the controller cache disabled. Now try it with the controller cache disabled and running on a true 4k sector drive. Spoiler: good, bad, worse.
-
ToDo: https://redmine.pfsense.org/issues/4847
-
The bug was already filed. Considering people have been complaining just for 3+ years, this definitely can wait. The IPv6 fragmention bug in pf has been filed just ~7 years ago – and of course still well alive and kicking. Welcome to FreeBSD's kernel land, brace for impact!
Does it worry anybody else that pfSense dev's accept code commits from this "genius"?
Hey look, even FreeBSD upstream says you know what you're talking about:
Support for detecting and implementing aligning partitions on 1Mb boundaries has been added to bsdinstall(8). [r285721]
https://svnweb.freebsd.org/base?view=revision&revision=285721Huh… wonder why they would make a change like that.
-
Does it worry anybody else that pfSense dev's accept code commits from this "genius"?
nope.
