On Tuesday 04 of October 2011 02:02:31 erik quanstrom wrote:
> xp won't use it correctly either. in fact, if you're using a standard
> fdisk layout, chances are things are a little sideways on nearly any
> os.
>
> in any event, if i were buying a 2t hard drive today, i'd get
> http://www.ne
I said:
>> You could try telling your BIOS to use the disk in ATA (IDE) mode, and
>> see if that gives you 512-byte sector emulation. However I seem to
>> recall posts from Erik advising that some chipsets have bugs in this
>> mode which affect Plan 9.
quans...@quanstro.net said:
> to put a poi
quans...@quanstro.net:
> you may use 512
> byte sectors if you really want to suffer terrible performance
> (usually 1/3 the normal performance for reasonablly random
> workloads.)
Why will performance be terrible using 512-byte logical sectors on a
4096-byte physical sector disk? Both fossil and
quans...@quanstro.net:
> word 106 6003 [valid=1]
> multiple log/phys? 1
> log/phys 8
> logical sector size 0 [valid=0]
On my WD10EARS, word 106 of the ATA identify block is 0, indicating
no support for logical sectors.
I've just tried the experiment of creating eight 1GB partitions
aligned
perhaps there's an option bit?
On 4 October 2011 12:28, Richard Miller <9f...@hamnavoe.com> wrote:
> This all seems to contradict WD's claim (*) that the WD10EARS is an
> advanced format drive.
>
> perhaps there's an option bit?
If the drive was physically formatted with 4096-byte sectors,
I can't see how changing a logical bit could prevent unaligned
writes from causing a read-modify-write cycle.
no, i meant to select what the drive advertises. it would be a bit
disconcerting if flipping a bit had to reformat a drive!
On 4 October 2011 13:01, Richard Miller <9f...@hamnavoe.com> wrote:
> > perhaps there's an option bit?
>
> If the drive was physically formatted with 4096-byte sectors,
> I
On Tue Oct 4 07:29:18 EDT 2011, 9f...@hamnavoe.com wrote:
> quans...@quanstro.net:
> > word 106 6003 [valid=1]
> > multiple log/phys? 1
> > log/phys 8
> > logical sector size 0 [valid=0]
>
> On my WD10EARS, word 106 of the ATA identify block is 0, indicating
> no support for logical sectors
On Tue Oct 4 08:02:13 EDT 2011, 9f...@hamnavoe.com wrote:
> > perhaps there's an option bit?
>
> If the drive was physically formatted with 4096-byte sectors,
> I can't see how changing a logical bit could prevent unaligned
> writes from causing a read-modify-write cycle.
you aren't up with the
i see that to find all the answers i might have to pay $300 for an
individual membership to another organisation;
probably the membership will be about as useful as the VGA ones. thieving
bastards.
> the other guy has a WD20EARS which is a completely different drive.
Sure, but all the EARS series are claimed (in the spec sheet ref'd
in my previous message) to be advanced format i.e. 4096-byte physical
sectors.
On Tuesday 04 of October 2011 14:13:40 Charles Forsyth wrote:
> i see that to find all the answers i might have to pay $300 for an
> individual membership to another organisation;
> probably the membership will be about as useful as the VGA ones. thieving
> bastards.
if you'll excuse,
Q. What's
On Tue Oct 4 08:16:00 EDT 2011, 9f...@hamnavoe.com wrote:
> > the other guy has a WD20EARS which is a completely different drive.
>
> Sure, but all the EARS series are claimed (in the spec sheet ref'd
> in my previous message) to be advanced format i.e. 4096-byte physical
> sectors.
sure, that j
On Tue Oct 4 08:09:55 EDT 2011, charles.fors...@gmail.com wrote:
> no, i meant to select what the drive advertises. it would be a bit
> disconcerting if flipping a bit had to reformat a drive!
well they advertize *two* different sector sizes, a logical size and a
physical size. the drive never
> part test7 42249863 44249863 align 7
> term% for (i in /dev/sdC0/test?) { time rc -c 'dd -if /dev/zero -of '$i' -bs
> 4k -count 25 >[2]/dev/null' }
> 0.57u 8.43s 20.40r rc -c dd -if /dev/zero -of /dev/sdC0/test0 -bs 4k
> -count 25 >[2]/dev/null
> 0.50u 8.65s 20.71r rc -c dd -if
> i see that to find all the answers i might have to pay $300 for an
> individual membership to another organisation;
google ata.command.set filetype:pdf
gives you lots of free draft versions, pick one.
i had in mind something that would make the drive look as much like an old
drive as possible,
including lying about simply everything, including the underlying physical
sector size. surely that's
suitable for the PC heritage.
On 4 October 2011 13:17, erik quanstrom wrote:
> On Tue Oct 4 08:09:5
> 25*4096/20.78 = 49 mb/s. this is less than 1/2 the available
> bandwidth giving the drive lots of wiggle room. and since you're
> doing sequential i/o the drive can do write combining.
Is there any experiment I can do (not involving a crowbar and a
microscope) to find out the real physical
> i had in mind something that would make the drive look as much like an old
> drive as possible,
> including lying about simply everything, including the underlying physical
> sector size. surely that's
> suitable for the PC heritage.
we used to care what the c/h/s of a drive was. now we don't.
On Tuesday 04 of October 2011 14:33:27 Richard Miller wrote:
> > 25*4096/20.78 = 49 mb/s. this is less than 1/2 the available
> > bandwidth giving the drive lots of wiggle room. and since you're
> > doing sequential i/o the drive can do write combining.
>
> Is there any experiment I can do (
On Tuesday 04 of October 2011 14:52:49 dexen deVries wrote:
> compare write bandwidth for 4096B data chunks at offset modulo 512B:
> (n*512B+k), where `n' is random. compare 8 runs, each with const `k' from {
> 0, 1, ...7 }. sync after every write. write much more than drive cache
> size at each ru
Why can I not re-bind #M?
/sys/src/9/port/chan.c:1374
I want to use auth/newns to flush out my namespace
then build a new one including some bits of devcons.
Is this a security issue for cpu servers? I cannot see
what it is protecting me from.
Also, why is this done here and not in fsat
to save grief in the short term, i've disabled recognizing 4k sector drives
as 4k. as richard miller points out, this will allow one who carefully aligns
i/o and does so in chunks that are 0 mod 4k, to not incur r/m/w cycles.
(not that venti or fossil can push a disk hard enough for this to matter
#M is not a nameable device.
It is a pseudo-device representing mounted connections.
Instead of writing
bind -b #M123 /dev
You are supposed to write
mount -b /srv/whatever /dev
My memory is that the name space files use
the latter form unless the original name is gone.
Russ
#M, but devcons? devcons is #c
On 4 October 2011 14:34, Steve Simon wrote:
> then build a new one including some bits of devcons.
...
>
> Also, why is this done here and not in fsattach() of devcons
> (with a refcount)?
> Is there any experiment I can do (not involving a crowbar and a
> microscope) to find out the real physical sector size? Bigger
> transfers get more of the bandwidth, but then a smaller proportion
> of the transfer needs read/modify/write. I could do random addressing
> but then I would expect
> i think the attached program ought to work.
Doing i/o to random blocks, aren't you mostly measuring seek time?
On Tue Oct 4 11:57:27 EDT 2011, 9f...@hamnavoe.com wrote:
> > i think the attached program ought to work.
>
> Doing i/o to random blocks, aren't you mostly measuring seek time?
the drive will write-combine sequential io, so that's not an option.
i've definately seen artifacts when doing complete
> you can try rewriting it to step by 8k and retry the test.
Bingo, thanks.
I was still trying to figure out how to force the drive to sync
as Dexen suggested (maybe using scsicmd to issue an ata FLUSH CACHE
command?), but stepping by 8k does reveal a strong pattern.
Writing 25000 4k records ste
> > you can try rewriting it to step by 8k and retry the test.
>
> Bingo, thanks.
>
> I was still trying to figure out how to force the drive to sync
> as Dexen suggested (maybe using scsicmd to issue an ata FLUSH CACHE
> command?), but stepping by 8k does reveal a strong pattern.
you can either
Hi.
First of all sorry if I through my ignorance am attempting something
completely stupid.
I have been trying to copy the APE sources using plan9port. The
purpose of this is that I am trying to make an APE augmentation
PKGBUILD to the kencc package [1] (and ultimately, I will try to
figure out h
Sources and the plan9 website are unreachable at the moment. It appears
that 204.178.31.x hosts are unreachable, and since both ns1 and
ns2.cs.bell-labs.com are on that network, neither plan9.bell-labs.com or
*.cs.bell-labs.com are resolving.
that's certainly the linux way, although to be fair, its fsck does a really
good job of making a scramble worse.
that reminds me that i've still got a big file with a scrambled partition to
unscramble to
get back some big data i wanted to keep.
On 4 October 2011 17:45, erik quanstrom wrote:
> it
On Tuesday 04 October 2011 19:52:10 Charles Forsyth wrote:
> that's certainly the linux way, although to be fair, its fsck does a really
> good job of making a scramble worse.
for those stuck on linux:
http://www.nilfs.org/en/ is quite immune to inconsistencies on dirty shutdown,
yet performs wel
> What I now wonder is: Is this the expected behaviour?
No. You are doing it fine.
It's working for me right now, authenticated and unauthenticated.
I don't know why it doesn't work for you.
Beware "9 mount" should be spelled "9mount" in your messages.
What kernel version are you using?
--
Dav
On Tue, 04 Oct 2011 12:45:58 EDT erik quanstrom wrote:
> > Writing 25000 4k records stepping by 8k takes
> > sector offset 1-7 mod 8: 27-30 sec
> > sector offset 0 mod 8: 14-17 sec
> >
> > Conclusion: WD10EARS has 4k byte physical sectors but is pretty
> > good at concealing it.
Weren't t
On Tue Oct 4 14:25:29 EDT 2011, ba...@bitblocks.com wrote:
> On Tue, 04 Oct 2011 12:45:58 EDT erik quanstrom
> wrote:
> > > Writing 25000 4k records stepping by 8k takes
> > > sector offset 1-7 mod 8: 27-30 sec
> > > sector offset 0 mod 8: 14-17 sec
> > >
> > > Conclusion: WD10EARS has 4
I can't spot anything obvious. I'm not aware of anyone trying
Plan 9 on xen on NetBSD before, so maybe there's something different
in that environment.
> -rw-r--r-- 1 root wheel 1073741824 Sep 26 08:08 plan9.img
You could try 'chmod 666 plan9.img', just in case it's a permission thing.
2011/10/4 David du Colombier <0in...@gmail.com>:
>> What I now wonder is: Is this the expected behaviour?
>
> No. You are doing it fine.
> It's working for me right now, authenticated and unauthenticated.
>
> I don't know why it doesn't work for you.
> Beware "9 mount" should be spelled "9mount" in
What does 'mount' (not 9 mount, just mount)
say after you mount the file system?
That will tell you whether the '9 mount' used
v9fs (Linux 9P driver) or 9pfuse (user-space
9P-to-FUSE translator).
Neither gets much use, so it is easy to believe
that there is a bug.
Russ
> I can then cd and explore the bell labs sources via
> plan9port, so that
> works just fine.
>
> When I then try something like
>
> cp -ar sources/plan9/sys/src/ape ape
>
> I get an error stating:
> unexpected open flags 050cp: can not open
> ”sources/plan9/sys/src/ape/9src/mkfile” for read
To answer my question: the error message comes from 9pfuse.
The extra bits are O_NOFOLLOW and O_LARGEFILE, both of
which seem harmless in this context. Try this:
diff -r 6db8fc2588f6 src/cmd/9pfuse/main.c
--- a/src/cmd/9pfuse/main.c Mon Oct 03 18:16:09 2011 -0400
+++ b/src/cmd/9pfuse/main.c
2011/10/4 Russ Cox :
> What does 'mount' (not 9 mount, just mount)
> say after you mount the file system?
>
> That will tell you whether the '9 mount' used
> v9fs (Linux 9P driver) or 9pfuse (user-space
> 9P-to-FUSE translator).
>
> Neither gets much use, so it is easy to believe
> that there is a
2011/10/4 Russ Cox :
> To answer my question: the error message comes from 9pfuse.
> The extra bits are O_NOFOLLOW and O_LARGEFILE, both of
> which seem harmless in this context. Try this:
>
>
> diff -r 6db8fc2588f6 src/cmd/9pfuse/main.c
> --- a/src/cmd/9pfuse/main.c Mon Oct 03 18:16:09 2011 -
Perhaps, Steve wants rio-simulated /dev/cons.
Steve, doesn't mount -b $wsys /dev in the new ns do the trick?
2011/10/4 Charles Forsyth :
> #M, but devcons? devcons is #c
>
> On 4 October 2011 14:34, Steve Simon wrote:
>>
>> then build a new one including some bits of devcons.
>
> ...
>>
>> Also,
i got motivated and fixed radar so that,
- /lib/sky here is used to find the "nearest" radar station, and
- if you enter an arbitrary (us, sorry) location like "eden prarie mn", radar
will find the "nearest" radar station and display that.
i spent a few minutes looking for decent european radars,
> i got motivated and fixed radar so that,
> - /lib/sky here is used to find the "nearest" radar station, and
> - if you enter an arbitrary (us, sorry) location like "eden prarie mn", radar
> will find the "nearest" radar station and display that.
Very cool, it seems to be working quite well excep
On Wed Oct 5 01:13:08 EDT 2011, s...@9p.sdf.org wrote:
> > i got motivated and fixed radar so that,
> > - /lib/sky here is used to find the "nearest" radar station, and
> > - if you enter an arbitrary (us, sorry) location like "eden prarie mn",
> > radar
> > will find the "nearest" radar station
> > I added: LGX Langley Hill WA to lib/stations and LGX 47.109 -124.100
> > (approx) to lib/stationlat
> >
> > There is an interesting read about getting the array going and what it
> > will do for Western Washington here: http://tx0.org/2uy
>
> i think it's already there. what you saw was pro
49 matches
Mail list logo
