Hi Christian,
if you were to have a 1MB file or a database that needed to read 1MB
of data, i
f the partitions are not aligned then
your underlying storage system need to load 2 chunks or write 2
chunks for 1 MB of data, written,
So *worst* case you would double the workload for the storage ha
On Wed, Apr 21, 2021 at 08:20:10AM +0100, Tom Smyth wrote:
> Hi Christian,
>
> if you were to have a 1MB file or a database that needed to read 1MB
> of data, i
> f the partitions are not aligned then
> your underlying storage system need to load 2 chunks or write 2
> chunks for 1 MB of data,
Hello Otto, Christian,
I was relying on that paper for the pictures of the alignment issue,
VMFS (vmware file system)since version 5 of vmwarehas allocation
units of 1MB each
https://kb.vmware.com/s/article/2137120
my understanding is that SSDs have a similar allocation unit setup of 1MB
Hi all,
I have tested if the trusted boot implementation
of Julius Zint for OpenBSD 6.5
(https://marc.info/?l=openbsd-misc&m=158255450604977&w=2)
is still working in OpenBSD 6.8.
Despite of some patch files that had to be updated,
all changes needed to be applied can be applied and
Trusted Boot c
On Wed, Apr 21, 2021 at 09:56:59AM +0100, Tom Smyth wrote:
> Hello Otto, Christian,
>
> I was relying on that paper for the pictures of the alignment issue,
>
> VMFS (vmware file system)since version 5 of vmwarehas allocation
> units of 1MB each
>
> https://kb.vmware.com/s/article/2137120
Tom Smyth:
> if you were to have a 1MB file or a database that needed to read 1MB
> of data, i
> f the partitions are not aligned then
> your underlying storage system need to load 2 chunks or write 2
> chunks for 1 MB of data, written,
You seem to assume that FFS2 would align a 1MB file on an
Christian, Otto, Thanks for your feedback on this one
Ill research it further,
but NTFS has 4K, 8K 32K and 64K Allocation units on the
filessystem and for Microsoft windows running Exchange or Database workloads
they were recommending alignment of the NTFS partitions
on the 1MB offset also.
I’m running OpenBSD on top of bHyve using virtual disks allocated out of ZFS
pools. While not the same setup, some concepts carry over…
I have two types of pools:
1) an “expensive" pool for fast random IO:
- this pool is made up stripes of SSD-based vdevs.
- ZFS is configured
[My previous message was somewhat garbled when reflected back at me. It looks
better in the archives here:
https://marc.info/?l=openbsd-misc&m=161902769301731&w=2. I’m resending as
plain-text to see if the problem is on my end.]
I’m running OpenBSD on top of bHyve using virtual disks allocat
On 2021-04-21, Kent Watsen wrote:
> - When ZFS is told to use the SSD, it starts the partition
> on sector 256 (not the default sector 34) to ensure good
> SSD NAND alignment.
The OS doesn't get all that close to the NAND layer with typical
computer component SSD drives, t
Whereof everyone is interested,
A few things about his architecture is extraordinary special.
#1 ideal properties, can never be done better for some things.
#1.1 analogue, you need ground and good drain, to do work during weak force
pull.
#1.2 physical, independent IC's, relying on physics for
My ssh keys make more sense than this gibberish.
Balder Oddson writes:
> Whereof everyone is interested,
>
>
>
> A few things about his architecture is extraordinary special.
>
> #1 ideal properties, can never be done better for some things.
> #1.1 analogue, you need ground and good drain, to do
>On the one hand, where this gives 8x the performance at a high price, it
>likely caused as much awe, inspiration and anxiety in the finance sector
>where Cray got the funding to research, build and sell these beasts.
>
>The Cult of the Holy Cow, and The Cult of the Dead Cow are oxymorons if
>the c
That's very interesting, and good work patching the assembly code.
On Wed, Apr 21, 2021 at 08:26:18AM +, podolica wrote:
Hi all,
I have tested if the trusted boot implementation
of Julius Zint for OpenBSD 6.5
(https://marc.info/?l=openbsd-misc&m=158255450604977&w=2)
is still working in Ope
14 matches
Mail list logo