On 3/24/10 3:09 AM, Andrew Doran wrote:
The comment that pthread_* functions cannot safely be used in the forked
child is not QUITE what I understand to be what POSIX has in mind. They
say only one thread is running (that is, the child's MAIN thread).
Creating another thread afterwards should be
with this patch (which I am about to commit to current) is
not perfect, but it is at least a large chunk of the problem.)
--Michael
shouldn't?
--Michael
On 3/23/10 7:08 PM, Joerg Sonnenberger wrote:
On Tue, Mar 23, 2010 at 07:03:11PM -0700, Michael Graff wrote:
I'd like to commit it (and request a pull-up to netbsd-5). Any reason I
shouldn't?
What is the real problem here? fork(2) of a multithreaded program is
essentially Here be dragon's
, they're abundant, and cheap.
Nevertheless, there does not seem to be much interest in porting to
them. Why is that?
I don't care about hardware without graphics ;)
*duck*
have fun
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin
the requirement
to access physical sectors?
N.B. this is not about accessing the journal itself
which has other requirements for ordering and atomicity.
--
--
Michael van Elst
Internet: mlel...@serpens.de
A potential Snark may lurk
mention of this?
The datasheet itself does not mention any preference in regard to the type.
In the wiki on lm-sensors.org I could find only one configuration which
actually uses the temperature sensors of the W83627HF. This configuration
also configures it to use the 3904 mode.
Best regards,
Michael
Hi Paul,
Excerpts from Paul Goyette's message of Mo Feb 08 00:14:44 +0100 2010:
Can you try the attached diff, and set 'flags 1' in your config file?
The patch works fine. I would suggest to use flag 2, however, to be consistent
with the linux driver.
Best regards,
Michael
-fs_sblockloc (fs-fs_fshift - fs-fs_fsbtodb), FFS_NOBLK,
+ fs-fs_sblockloc / DEV_BSIZE, FFS_NOBLK,
fs-fs_sbsize, false, bp);
if (error)
return error;
Please commit.
--
Michael van Elst
Internet: mlel...@serpens.de
On Tue, Feb 02, 2010 at 08:19:40AM +, David Holland wrote:
On Mon, Feb 01, 2010 at 08:58:31PM +, Michael van Elst wrote:
The superblock already stores block sizes in terms of byte counts.
The problem is that it stores information that shouldn't be there but
which depends only
are not related to addressing disk blocks.
I would not expect issues there as the code has been used on disks
with different block sizes in the past. Maybe there are bugs in
the dirhash code.
Greetings,
--
Michael van Elst
Internet: mlel...@serpens.de
.
--
--
Michael van Elst
Internet: mlel...@serpens.de
A potential Snark may lurk in every tree.
On Mon, Feb 01, 2010 at 09:10:05PM +, David Laight wrote:
On Mon, Feb 01, 2010 at 08:58:31PM +, Michael van Elst wrote:
The superblock already stores block sizes in terms of byte counts.
The problem is that it stores information that shouldn't be there but
which depends only
== sectors).
The only solution is expensive buffering and read-modify-write updates.
Fortunately this is a pretty academic problem and I don't see a reason
to solve this problem in the kernel. There are plenty of alternatives.
--
--
Michael van Elst
Internet: mlel
coordinates on other systems). Everything
became 512-byte-sector devices when or shortly after NetBSD
imported the current SCSI framework.
--
--
Michael van Elst
Internet: mlel...@serpens.de
A potential Snark may lurk in every tree.
On Mon, Feb 01, 2010 at 07:48:01PM -0500, Thor Lancelot Simon wrote:
On Mon, Feb 01, 2010 at 10:59:37PM +, Michael van Elst wrote:
It still wouldn't be perfect. Block size is one thing, block alignment
the next. A filesystem with 1k blocks (filesystem units == clusters)
has problems
, vnd, ...) but I don't
expect any problems.
Can you please test with your 2K MO?
N.B. newfs doesn't yet know how to deduce sector sizes, you need
to use the -S option.
--
--
Michael van Elst
Internet: mlel...@serpens.de
A potential
doesn't yet know how to deduce sector sizes, you need
to use the -S option.
newfs(8) doesn't work even with -S 2048 option.
It now does :) Still, it should not need that option.
--
--
Michael van Elst
Internet: mlel...@serpens.de
.
--
--
Michael van Elst
Internet: mlel...@serpens.de
A potential Snark may lurk in every tree.
.
--
Michael van Elst
Internet: mlel...@serpens.de
A potential Snark may lurk in every tree.
) don't work on !512bytes/sec disks)
Yes, pretty much hardcoded.
BPB also uses physical block numbers.
The msdosfs code should handle all block sizes (also on GPT volumes now).
--
--
Michael van Elst
Internet: mlel...@serpens.de
,
--
Michael van Elst
Internet: mlel...@serpens.de
A potential Snark may lurk in every tree.
of places (unrelated to DEV_BSIZE) that could
be structured better and cleaned up, e.g. partition handling.
And all this should be done, wether you intend to drop or
keep DEV_BSIZE.
--
--
Michael van Elst
Internet: mlel...@serpens.de
of using information
from the driver) is what I consider questionable.
--
--
Michael van Elst
Internet: mlel...@serpens.de
A potential Snark may lurk in every tree.
On Sun, Jan 24, 2010 at 11:16:05PM +1030, Brett Lymn wrote:
On Fri, Jan 22, 2010 at 01:09:10PM +0100, Michael van Elst wrote:
Keeping DEV_SIZE at 512 bytes avoids lots of changes.
Won't that mean there is a chance there will be a lot of
read/modify/write going on if the driver
} and I learned that the block size translation is already done
} in our block drivers, so there is no need to funnel I/O through dk.
It is certainly good to have a proof of concept.
I think the best is to just ignore your chatter.
--
Michael van Elst
On Sun, Jan 24, 2010 at 09:54:47PM +, David Holland wrote:
On Sun, Jan 24, 2010 at 08:48:07PM +0100, Michael van Elst wrote:
A quote, often attributed to Einstein, is, Everything should be
made as simple as possible, but no simpler. I can't help but feel
that this is making
advantages.
--
--
Michael van Elst
Internet: mlel...@serpens.de
A potential Snark may lurk in every tree.
jo...@britannica.bec.de (Joerg Sonnenberger) writes:
For FFS2 it doesn't matter ATM, because
it is broken in that regard anyway, I think.
Fix it...
--
--
Michael van Elst
Internet: mlel...@serpens.de
A potential Snark may lurk
) only internally to some subsystem where
these have a meaning and to use byte counts between those subsystems.
After all, the hardware does use blocks.
Quotas should use the units the filesystem uses. For FFS that's
probably fragments.
--
--
Michael van Elst
On Fri, Jan 22, 2010 at 02:28:07PM +0700, Robert Elz wrote:
Date:Fri, 22 Jan 2010 08:07:03 +0100
From:Michael van Elst mlel...@serpens.de
Message-ID: 20100122070702.ga10...@serpens.de
| except that there a lot of assumptions that
| physical block size
601 - 631 of 631 matches
Mail list logo
