On 2017-04-05 18:05, Theo de Raadt wrote:
..
>> So presently higher-speed access is restricted to read()/write() -
>> noted.
>
> So what?
Yeah you're right - while some really nice code out there such as LMDB
depends on mmap, and mmap may be a bliss in how it abstracts away the
externality of a
(Not moving to misc@ as I expect this to be the last correspondence
round on this topic)
On 2017-04-05 17:36, Theo de Raadt wrote:
On 2017-04-05 17:24, Theo de Raadt wrote:
>> "ls -l /dev/rsd0c; ls -l /dev/sd0c" shows that sd0c is a block device
>> and rsd0c is a character device, and mmap's
On 2017-04-05 17:24, Theo de Raadt wrote:
"ls -l /dev/rsd0c; ls -l /dev/sd0c" shows that sd0c is a block device
and rsd0c is a character device, and mmap's man page says that
"character special files" are OK.
The manual pages will never list all restrictions.
/dev/sd* delivers ~120MB/sec
st place.
Is it possible to do any way?
Thanks,
Tinker
Example trymap.c below:
# gcc -o trymap trymap.c
# ./trymap /dev/sd0c
Opened /dev/sd0c with handle 3.
mmap succeeded.
# ./trymap /dev/rsd0c
Opened /dev/rsd0c with handle 3.
mmap failed, errno 22: Invalid argument.
Changing to O_RDWR and PROT
ffer cache
size limit), that would be interesting to learn to know.
Thanks!
Tinker
On 2016-08-13 11:34, Theo de Raadt wrote:
I have to admit, it's a bit shocking that VOLTAGE REGULATORS have to
be
exposed to the software in the first place.
Just imagine a bug in some OS or firmware causing the voltages to
spike
up and fry the hell out of a device.
I guess that's modern-day
On 2016-06-23 05:42, Theo de Raadt wrote:
secondly, allocating more than 4g at a time to socket buffers is
generally a waste of memory.
and there is one further problem.
Eventually, this subsystem will starve the system. Other subsystems
which also need large amounts of memory, then have to
On 2016-08-11 08:30, Mark Kettenis wrote:
Finally found the pmap bug that kept Cortex-A7 from working. Turns
out we have to flush the TLB when removing a L1 slot as well. Already
committed the diff, but here it is for those that are interested.
For the unintroduced but curious, of what
On 2016-02-01 16:29, Janne Johansson wrote:
2016-01-31 9:24 GMT+01:00 Tinker <ti...@openmailbox.org>:
Q1:
My most important question to you is, the DATA that you CHECKSUM, do
you
include the SECTOR NUMBER (or other disk location info) of that data
into
your checksum function's inpu
If it did, then everything would break for all filesystems, so that is
obviously not how it is done.
2016-02-01 11:11 GMT+01:00 Tinker <ti...@openmailbox.org>:
On 2016-02-01 16:29, Janne Johansson wrote:
2016-01-31 9:24 GMT+01:00 Tinker <ti...@openmailbox.org>:
Q1:
My most important questi
k & SSD with super cap / fault tolerant on disk cache
can
seed up I/O significantly..
Can you give a practical example of this?
)
Thanks,
Tinker
(Moving to misc@ only)
On 2016-02-01 11:14, Patrick Dohman wrote:
Do you know any MegaRaid that a) supports that, b) is modern and not
archaic, and c) is supported by OpenBSD?
It appears the MFI driver provides support for the MegaRAID SAS 9260-8i
Pleas note I’ve not tested the 9260-8i
This could be made in software with benefit, as a Softraid patch.
So the frequently accessed stuff ends up cached on the SSD for faster
read speed.
ZFS on FreeBSD etc. does it in its "ARC"/"ARC2L" feature?
There is some hardware solution, e.g. Intel made the
.
Q4:
What is your status on getting RAID1C included into OpenBSD?
Thanks!
Tinker
for making this happen,
if so how big a donation, of what value would USD 1,000 be in
proportion?
Not sure right now but next 12 months I could consider this, if you
have any ideas about who feel free to respond or PM or anything you
like.
On 2016-01-31 16:16, Tinker wrote:
This could be made
Ah, I now understand that this problem is mindbogglingly complex because
of tons and tons of work needed to make it work, including the storage
format on the SSD cache, and tools for "fsck":ing it etc etc. In a way
that maybe answered my question, thanks!
On 2016-01-31 19:00, Ti
Migrating this thread to misc@ .
On 2016-01-31 16:24, Tinker wrote:
Hi Karel,
Can you please tell me, about your RAID1C patch:
So basically, your RAID1C patch is just the ordinary softraid, BUT,
with checksums for each sector, located right at the end of the
physical disc.
Q1:
My most
17 matches
Mail list logo
