[9fans] Thinkpad T61 Installation Experience

[9fans] Thinkpad T61 Installation Experience

[Burton Samograd]

I got my Thinkpad T61 last night and installation was somewhat
successful but not without problems:

- the main thing was to set the SATA controller to 'Compatibility'
mode.  9front would find the disk
  and install correctly but would get stuck after the pbs if this was
not set.  The bell labs iso would
  boot but not find the disk leading to some confusion when I didn't
notice it was trying to partition
  the install CD during installation

- after setting to Compatibility mode the Bell Labs iso install would
go along well until it was trying
  to copydist which then was either completely failing or going
incredibly slow; I waited at least 15
  minutes during this process and it was at around 3% before I gave
up.  The cd would spin up and
  down but it really didn't seem to be copying anything at all or at
least nothing very quickly.

- the middle mouse button doesn't work when using ps2intellimouse or ps2

- graphics works great at native 1280x800x16 resolution

- wired networking works good

So, in the end I got 9front installed but now the bell labs wiki isn't
very helpful since so much has
changed, with the first being how to add a new user among other
things.  To be honest, I'd rather
be using the Bell Labs iso so if anybody could give a suggestion on
how to get that working I'd
appreciate it.

--
Burton Samograd

Re: [9fans] Thinkpad T61 Installation Experience

[Bruce Ellis]

a friend gave me a T61 and the bell-labs iso installed just fine. i
can't recall using any tricks, pretty much however the bios was
configured - i did it in the pub.

brucee

On 16 May 2012 22:24, Burton Samograd <burton.samograd@gmail.com> wrote:
> I got my Thinkpad T61 last night and installation was somewhat
> successful but not without problems:
>
> - the main thing was to set the SATA controller to 'Compatibility'
> mode.  9front would find the disk
>  and install correctly but would get stuck after the pbs if this was
> not set.  The bell labs iso would
>  boot but not find the disk leading to some confusion when I didn't
> notice it was trying to partition
>  the install CD during installation
>
> - after setting to Compatibility mode the Bell Labs iso install would
> go along well until it was trying
>  to copydist which then was either completely failing or going
> incredibly slow; I waited at least 15
>  minutes during this process and it was at around 3% before I gave
> up.  The cd would spin up and
>  down but it really didn't seem to be copying anything at all or at
> least nothing very quickly.
>
> - the middle mouse button doesn't work when using ps2intellimouse or ps2
>
> - graphics works great at native 1280x800x16 resolution
>
> - wired networking works good
>
> So, in the end I got 9front installed but now the bell labs wiki isn't
> very helpful since so much has
> changed, with the first being how to add a new user among other
> things.  To be honest, I'd rather
> be using the Bell Labs iso so if anybody could give a suggestion on
> how to get that working I'd
> appreciate it.
>
> --
> Burton Samograd
>



-- 
Don't meddle in the mouth -- MVS (0416935147, +1-513-3BRUCEE)

Re: [9fans] Thinkpad T61 Installation Experience

[Burton Samograd]

On Wed, May 16, 2012 at 6:32 AM, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> a friend gave me a T61 and the bell-labs iso installed just fine. i
> can't recall using any tricks, pretty much however the bios was
> configured - i did it in the pub.

Did you have DMA enabled on the disks?  I chose yes at that prompt now I'm
wondering if that might have been part of the problem.  Do all the buttons on
the mouse work?

I'm still at the iterative install over and over again phase so I'll
probably try it
again just to see if it works a different time.  Maybe I'll give 9atom
a shot too;
lots of new stuff to try.

--
Burton Samograd

Re: [9fans] Thinkpad T61 Installation Experience

[Peter A. Cejchan]

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

> again just to see if it works a different time.  Maybe I'll give 9atom
> a shot too

I had to switch to 9atom some time asgo whe I bought my first sata-ii hd
(but it was not on a laptop). If there is an option "Configure SATA(or IDE)
as AHCI" in your BIOS,
use it.

regards,
++pac

[-- Attachment #2: Type: text/html, Size: 374 bytes --]

Re: [9fans] Thinkpad T61 Installation Experience

[David du Colombier]

> The bell labs iso would boot but not find the disk leading
> to some confusion when I didn't notice it was trying to
> partition the install CD during installation

Which Plan 9 CD image have you tried? The first Plan 9 CD
including the new bootstraps was published just yesterday.

> after setting to Compatibility mode the Bell Labs iso install
> would go along well until it was trying to copydist which
> then was either completely failing or going incredibly slow;
> I waited at least 15 minutes during this process and it was
> at around 3% before I gave up.  The cd would spin up and
> down but it really didn't seem to be copying anything at
> all or at least nothing very quickly.

Have you enabled DMA at the begin of the installation
process? Whitout DMA, your disk i/o will likely be
something like ten times slower.

--
David du Colombier

Re: [9fans] Thinkpad T61 Installation Experience

[sl]

This is the plan9.ini on my T61, for use with the latest
9front kernel. With these settings mp, Ethernet and USB
all work (the integrated mouse button 2 does not work).:

bootfile=9pcf
bootargs=local!/dev/sdE0/fscache
nobootprompt=local!/dev/sdE0/fscache
nvram=/dev/sdE0/nvram
mouseport=ps2
monitor=vesa
vgasize=1280x800x32
*msi=1
user=sl
*mp=400
*mp0=00 00 14 03 fb 06 00 00 ff fb eb bf 00 00 00 00
*mp1=00 00 00 00 00 01 14 01 fb 06 00 00 ff fb eb bf
*mp2=00 00 00 00 00 00 00 00 01 00 50 43 49 20 20 20
*mp3=01 03 50 43 49 20 20 20 01 15 50 43 49 20 20 20
*mp4=01 16 49 53 41 20 20 20 02 02 20 01 00 00 c0 fe
*mp5=03 03 05 00 16 00 02 00 03 00 05 00 16 01 02 01
*mp6=03 00 05 00 16 00 02 02 03 00 05 00 16 03 02 03
*mp7=03 00 05 00 16 04 02 04 03 00 05 00 16 05 02 05
*mp8=03 00 05 00 16 06 02 06 03 00 05 00 16 07 02 07
*mp9=03 00 05 00 16 08 02 08 03 00 05 00 16 09 02 09
*mp10=03 00 05 00 16 0a 02 0a 03 00 05 00 16 0b 02 0b
*mp11=03 00 05 00 16 0c 02 0c 03 00 05 00 16 0d 02 0d
*mp12=03 00 05 00 16 0e 02 0e 03 00 05 00 16 0f 02 0f
*mp13=04 03 05 00 16 00 ff 00 04 01 05 00 16 00 ff 01
*mp14=03 00 00 00 00 04 02 10 03 00 00 00 00 0D 02 11
*mp15=03 00 00 00 00 0E 02 12 03 00 00 00 00 64 02 14
*mp16=03 00 00 00 00 68 02 14 03 00 00 00 00 69 02 15
*mp17=03 00 00 00 00 6A 02 16 03 00 00 00 00 6D 02 11
*mp18=03 00 00 00 00 70 02 14 03 00 00 00 00 71 02 15
*mp19=03 00 00 00 00 72 02 16 03 00 00 00 00 73 02 17
*mp20=03 00 00 00 00 74 02 10 03 00 00 00 00 75 02 11
*mp21=03 00 00 00 00 76 02 12 03 00 00 00 00 77 02 13
*mp22=03 00 00 00 00 7D 02 10 03 00 00 00 00 7E 02 10
*mp23=03 00 00 00 03 00 02 11 03 00 00 00 15 00 02 10
*mp24=03 00 00 00 15 01 02 11 03 00 00 00 15 02 02 12

-sl

Re: [9fans] Thinkpad T61 Installation Experience

[Nicolas Bercher]

Le 16/05/2012 14:24, Burton Samograd a écrit :
> So, in the end I got 9front installed but now the bell labs wiki isn't
> very helpful since so much has
> changed, with the first being how to add a new user among other
> things.  To be honest, I'd rather
> be using the Bell Labs iso so if anybody could give a suggestion on
> how to get that working I'd
> appreciate it.

As far as I can tell dmaon is important.

As a beginner, I always refer to this doc when I install a new Plan 9
system:

   http://mirror.9grid.fr/mirror.9grid.fr/plan9-cpu-auth-server-howto.html

Even if it's focused on the installation of an all-in-one cpu/fs/auth
machine, in the end, many steps are the same for the set up of a
terminal.  Better than that, you could set up a dual machine that can
be booted as a cpu/fs/auth or as a terminal.

Nicolas

Re: [9fans] Thinkpad T61 Installation Experience

[Nicolas Bercher]

Le 16/05/2012 15:14, David du Colombier a écrit :
> Have you enabled DMA at the begin of the installation
> process? Whitout DMA, your disk i/o will likely be
> something like ten times slower.

Is there any remaining reason today for dmaon not being the default?

Nicolas

Re: [9fans] Thinkpad T61 Installation Experience

[erik quanstrom]

On Wed May 16 09:52:32 EDT 2012, nbercher@yahoo.fr wrote:
> Le 16/05/2012 15:14, David du Colombier a écrit :
> > Have you enabled DMA at the begin of the installation
> > process? Whitout DMA, your disk i/o will likely be
> > something like ten times slower.
> 
> Is there any remaining reason today for dmaon not being the default?

no.  though i doubt there would be a 10x reduction in performance.
one could reasonablly get 10mb/s with pio.  (if it working.)  that's
probablly about as much as could be expected with the seekiness of
the original install.  as long as one isn't installing to something really
huge that needs preformatting, even 1mb/s should take no more than
500s (5 min).

- erik

Re: [9fans] Thinkpad T61 Installation Experience

[David du Colombier]

> Is there any remaining reason today for dmaon not being the default?

I don't think so, but I have this following patch still pending:

http://plan9.bell-labs.com/sources/patch/maybe/sdata-dma/

Erik also provides a way to enable DMA in plan9.ini,
as part of 9atom.

Personally, I ended up with this more drastic approach::

http://www.9legacy.org/9legacy/patch/pc-sdata-dma-lite.diff

It always enable DMA by default.

--
David du Colombier

Re: [9fans] Thinkpad T61 Installation Experience

[cinap_lenrek]

no, thats why we removed dmaon in 9front. we have a kernel
option now to disable dma, but default is enabled.

we also have virtio drivers for qemu/kvm.

--
cinap

Re: [9fans] Thinkpad T61 Installation Experience

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

actually, it is a huge difference. there's also "rwm on".

On 16 May 2012 15:05, erik quanstrom <quanstro@labs.coraid.com> wrote:

> no.  though i doubt there would be a 10x reduction in performance.
> one could reasonablly get 10mb/s with pio.  (if it working.)
>

[-- Attachment #2: Type: text/html, Size: 560 bytes --]

Re: [9fans] Thinkpad T61 Installation Experience

[David du Colombier]

> though i doubt there would be a 10x reduction in performance.

I already measured a 4MB/s to 40MB/s difference on
some controllers, but I don't have the exact numbers
and condition right now.

--
David du Colombier

Re: [9fans] Thinkpad T61 Installation Experience

[erik quanstrom]

On Wed May 16 10:27:24 EDT 2012, charles.forsyth@gmail.com wrote:

> actually, it is a huge difference. there's also "rwm on".
>
> On 16 May 2012 15:05, erik quanstrom <quanstro@labs.coraid.com> wrote:
>
> > no.  though i doubt there would be a 10x reduction in performance.
> > one could reasonablly get 10mb/s with pio.  (if it working.)

for an ide drive, you are correct.  but nobody has those anymore.

try again with modern hardware that is doing ide emulation to
a sata drive.  this effect, in combination with massive seek times,
means that pio shouldn't make a whole lot of difference.

- erik

Re: [9fans] Thinkpad T61 Installation Experience

[erik quanstrom]

On Wed May 16 10:25:41 EDT 2012, cinap_lenrek@gmx.de wrote:
> no, thats why we removed dmaon in 9front. we have a kernel
> option now to disable dma, but default is enabled.

i did the same, but 15 minutes.  since your only installing ~500mb,
and only about 50 or less got installed means the disk is doing 56kbps.
it's just broken.

- erik

Re: [9fans] Thinkpad T61 Installation Experience

[Martin Harriss]

Bruce Ellis wrote:
> a friend gave me a T61 and the bell-labs iso installed just fine. i
> can't recall using any tricks, pretty much however the bios was
> configured - i did it in the pub.

Is the fact that you did it in the pub the reason that you "can't recall"?

Re: [9fans] Thinkpad T61 Installation Experience

[Skip Tavakkolian]

2 or 3 years ago i installed the bell-labs iso on a Thinkpad T61p at
my office and it was uneventful.

like brucee, i can't recall using any tricks; so this could mean
either (a) no tricks were required or (b) there's something wrong with
my memory because clearly i would have had to jump through hoops.
Occam's razor naturally points to (b)  :)

-Skip

On Wed, May 16, 2012 at 7:43 AM, Martin Harriss <martin@princeton.edu> wrote:
> Bruce Ellis wrote:
>>
>> a friend gave me a T61 and the bell-labs iso installed just fine. i
>> can't recall using any tricks, pretty much however the bios was
>> configured - i did it in the pub.
>
>
> Is the fact that you did it in the pub the reason that you "can't recall"?
>

Re: [9fans] Thinkpad T61 Installation Experience

[erik quanstrom]

On Wed May 16 11:02:14 EDT 2012, skip.tavakkolian@gmail.com wrote:
> 2 or 3 years ago i installed the bell-labs iso on a Thinkpad T61p at
> my office and it was uneventful.
>
> like brucee, i can't recall using any tricks; so this could mean
> either (a) no tricks were required or (b) there's something wrong with
> my memory because clearly i would have had to jump through hoops.
> Occam's razor naturally points to (b)  :)

or, (c), there is not a single bios version for all t61s.

- erik

Re: [9fans] Thinkpad T61 Installation Experience

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 259 bytes --]

the hardware for different t23s, for instance, could be quite different.
i used to buy them up and swap the bits round.

On 16 May 2012 16:02, erik quanstrom <quanstro@labs.coraid.com> wrote:

> or, (c), there is not a single bios version for all t61s.

[-- Attachment #2: Type: text/html, Size: 524 bytes --]

Re: [9fans] Thinkpad T61 Installation Experience

[Burton Samograd]

Just curious, but what exactly to the mp[0..24] lines do?  And are they only supported by the 9front kernel?

--
Burton Samograd

-----Original Message-----
From: 9fans-bounces@9fans.net [mailto:9fans-bounces@9fans.net] On Behalf Of sl@9front.org
Sent: Wednesday, May 16, 2012 7:24 AM
To: 9fans@9fans.net
Subject: Re: [9fans] Thinkpad T61 Installation Experience

This is the plan9.ini on my T61, for use with the latest 9front kernel. With these settings mp, Ethernet and USB all work (the integrated mouse button 2 does not work).:

bootfile=9pcf
bootargs=local!/dev/sdE0/fscache
nobootprompt=local!/dev/sdE0/fscache
nvram=/dev/sdE0/nvram
mouseport=ps2
monitor=vesa
vgasize=1280x800x32
*msi=1
user=sl
*mp=400
*mp0=00 00 14 03 fb 06 00 00 ff fb eb bf 00 00 00 00
*mp1=00 00 00 00 00 01 14 01 fb 06 00 00 ff fb eb bf
*mp2=00 00 00 00 00 00 00 00 01 00 50 43 49 20 20 20
*mp3=01 03 50 43 49 20 20 20 01 15 50 43 49 20 20 20
*mp4=01 16 49 53 41 20 20 20 02 02 20 01 00 00 c0 fe
*mp5=03 03 05 00 16 00 02 00 03 00 05 00 16 01 02 01
*mp6=03 00 05 00 16 00 02 02 03 00 05 00 16 03 02 03
*mp7=03 00 05 00 16 04 02 04 03 00 05 00 16 05 02 05
*mp8=03 00 05 00 16 06 02 06 03 00 05 00 16 07 02 07
*mp9=03 00 05 00 16 08 02 08 03 00 05 00 16 09 02 09
*mp10=03 00 05 00 16 0a 02 0a 03 00 05 00 16 0b 02 0b
*mp11=03 00 05 00 16 0c 02 0c 03 00 05 00 16 0d 02 0d
*mp12=03 00 05 00 16 0e 02 0e 03 00 05 00 16 0f 02 0f
*mp13=04 03 05 00 16 00 ff 00 04 01 05 00 16 00 ff 01
*mp14=03 00 00 00 00 04 02 10 03 00 00 00 00 0D 02 11
*mp15=03 00 00 00 00 0E 02 12 03 00 00 00 00 64 02 14
*mp16=03 00 00 00 00 68 02 14 03 00 00 00 00 69 02 15
*mp17=03 00 00 00 00 6A 02 16 03 00 00 00 00 6D 02 11
*mp18=03 00 00 00 00 70 02 14 03 00 00 00 00 71 02 15
*mp19=03 00 00 00 00 72 02 16 03 00 00 00 00 73 02 17
*mp20=03 00 00 00 00 74 02 10 03 00 00 00 00 75 02 11
*mp21=03 00 00 00 00 76 02 12 03 00 00 00 00 77 02 13
*mp22=03 00 00 00 00 7D 02 10 03 00 00 00 00 7E 02 10
*mp23=03 00 00 00 03 00 02 11 03 00 00 00 15 00 02 10
*mp24=03 00 00 00 15 01 02 11 03 00 00 00 15 02 02 12

-sl


This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page

Please visit http://www.markit.com/en/about/contact/contact-us.page? for contact information on our offices worldwide.

Re: [9fans] Thinkpad T61 Installation Experience

[cinap_lenrek]

its a hexdump of the machines mp table. if you boot with *dumpmp=, the
kernel will dump its mp table to the console where it can be captured
from /dev/kmesg or other means like serial console.

normally, mp table is provided by the bios and placed in some memory
area where the kernel can find it. it basicly describes the machines
interrupt configuration, what busses there are, what processors ect.

the problem we had was that on sl's machine, the mptable just gives
us some legacy isa irq mapping. what we did was booting linux
(which uses acpi instead of mp table to acquire this information),
extracting the real interrupt mapping from dmesg and building a
fixed mp table that contains the real pci irq map.

with that, the irq sharing problems with usb are gone.

--
cinap

Re: [9fans] Thinkpad T61 Installation Experience

[Burton Samograd]

I think I'll have to stick with 9front.  I tried the official dist CD
and 9atom last night and both managed to install this time but
rebooting either of them would give a "no bootfile" error and a '>'
prompt that would take no input.  9front is the only dist that works
reliably enough to install a boot on this machine.

I have a question about the 9front/cwfs64x default partition layout,
which I picked because I'm a noob with this.  On my 80G did, it
suggested a ~10G other, ~10G fscache, and a ~50G fsworm parition.
After rebooting it looks like other is where my user directory is.  So
with this layout of the fs, does that mean I have 10G of user data
space, 10G for my 'root' file system and the other 50G is for the
wayback machine feature of the fs?  If so that seems pretty excessive,
but then again I don't think I'll be watching many movies on my p9
system so I think it will take me a while to fill up the 10G
allocated.

Could anybody explain the csfw64x default partitioning scheme on
9front a bit for me?  Thanks.

--
Burton Samograd

Re: [9fans] Thinkpad T61 Installation Experience

[erik quanstrom]

On Thu May 17 08:41:24 EDT 2012, burton.samograd@gmail.com wrote:
> I think I'll have to stick with 9front.  I tried the official dist CD
> and 9atom last night and both managed to install this time but
> rebooting either of them would give a "no bootfile" error and a '>'
> prompt that would take no input.  9front is the only dist that works
> reliably enough to install a boot on this machine

installing 9atom with the 9front boot loader doesn't work.  the
> prompt i a characteristic of it.

- erik

Re: [9fans] Thinkpad T61 Installation Experience

[Jack Norton]

On 5/17/2012 7:39 AM, Burton Samograd wrote:
> I think I'll have to stick with 9front.  I tried the official dist CD
> and 9atom last night and both managed to install this time but
> rebooting either of them would give a "no bootfile" error and a '>'
> prompt that would take no input.  9front is the only dist that works
> reliably enough to install a boot on this machine.
>
> I have a question about the 9front/cwfs64x default partition layout,
> which I picked because I'm a noob with this.  On my 80G did, it
> suggested a ~10G other, ~10G fscache, and a ~50G fsworm parition.
> After rebooting it looks like other is where my user directory is.  So
> with this layout of the fs, does that mean I have 10G of user data
> space, 10G for my 'root' file system and the other 50G is for the
> wayback machine feature of the fs?  If so that seems pretty excessive,
> but then again I don't think I'll be watching many movies on my p9
> system so I think it will take me a while to fill up the 10G
> allocated.
>
> Could anybody explain the csfw64x default partitioning scheme on
> 9front a bit for me?  Thanks.
>
> --
> Burton Samograd
>
  Please read cwfs(4) man page.  In there is a description of the
different partitions and their uses.  In particular you don't want
fscache to fill up as it causes the front to fall off.
It sounds also like you may need to read up on cache/worm filesystems in
general.  in your case 10G is not all you've got available for 'root',
just what you've got available for new writes between dumps to worm.

-Jack

Re: [9fans] Thinkpad T61 Installation Experience

[Burton Samograd]

> installing 9atom with the 9front boot loader doesn't work.  the
>> prompt i a characteristic of it.

Unless there was residuals from the previous install that weren't
overwritten then I was doing a clean install of both the labs and
9atom distro.

--
Burton Samograd

Re: [9fans] Thinkpad T61 Installation Experience

[Burton Samograd]

>  Please read cwfs(4) man page.  In there is a description of the different
> partitions and their uses.  In particular you don't want fscache to fill up
> as it causes the front to fall off.
> It sounds also like you may need to read up on cache/worm filesystems in
> general.  in your case 10G is not all you've got available for 'root', just
> what you've got available for new writes between dumps to worm.

Ok, I'll give it a read; I still have quite a bit to learn.  Thanks
for the brief explanation.

--
Burton Samograd

Re: [9fans] Thinkpad T61 Installation Experience

[erik quanstrom]

>   Please read cwfs(4) man page.  In there is a description of the
> different partitions and their uses.  In particular you don't want
> fscache to fill up as it causes the front to fall off.
> It sounds also like you may need to read up on cache/worm filesystems in
> general.  in your case 10G is not all you've got available for 'root',
> just what you've got available for new writes between dumps to worm.

remember that the bigger the cache, the more cache buckets you need,
and the more ram they will take up.  you can get into a situation where
most io is swapping cache buckets around, so a relatively small cache
is recommended.  (this is the same for cwfs and ken's file system.)
i'd recommend the relation 5gb of cache per gb of memory in the
fs block (memory) cache, but this isn't a scientific calcuation.

- erik

Re: [9fans] Thinkpad T61 Installation Experience

[erik quanstrom]

> I have a question about the 9front/cwfs64x default partition layout,
> which I picked because I'm a noob with this.  On my 80G did, it
> suggested a ~10G other, ~10G fscache, and a ~50G fsworm parition.
> After rebooting it looks like other is where my user directory is.  So
> with this layout of the fs, does that mean I have 10G of user data
> space, 10G for my 'root' file system and the other 50G is for the
> wayback machine feature of the fs?  If so that seems pretty excessive,
> but then again I don't think I'll be watching many movies on my p9
> system so I think it will take me a while to fill up the 10G
> allocated.

read /sys/doc/fs/fs.ps.  the worm is not a wayback machine, it is the
main storage!  however there is a coalescing period of 1 day where
changes are kept in the cache prior to being commited to worm.
the process of commiting changes to the worm is called the "dump".

so, for example, if i changed /rc/bin/P 10 days ago, the current
file tree would point to the same storage it did yesterday, and
both pointers would be into the worm.

- erik

Re: [9fans] Thinkpad T61 Installation Experience

[Burton Samograd]

> the worm is not a wayback machine, it is the main storage!

Maybe I was getting confused with venti (as in fossil+venti)?  I guess I thought that since cwfs was standalone that it incorporated both systems into one.

--
Burton Samograd


This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page

Please visit http://www.markit.com/en/about/contact/contact-us.page? for contact information on our offices worldwide.

Re: [9fans] Thinkpad T61 Installation Experience

[cinap_lenrek]

no. your user data is not in "other" filesystem. basicly there
are 3 filesystems that cwfs exports after 9front installation.
"main", "dump" and "other". "main" is the primary file system
that gets archived to the worm in daily intervals. the archival
snapshots (dump) appear as directories in the read only "dump"
filesystem. "main" is your root filesystem.

once stuff is written to the worm, it never gets deleted. you
can't discard dumps. they are there. forever.

the "other" filesystem is like a traditional unix filesystem.
its not dumped to worm and can be used kind of like scratch space.
we use it for the users /tmp directories.

you can do without a "other" fs. we added support for +t flags like
there is in fossil, so you can just mark directories and files
as temporary in the "main" filesystem so they dont get dumped
to worm. (this works recursively on directories)

but requires a bigger fscache partition if you have lots of stuff
flagged temporary. and you loose all your +t flagged data when
recovering the filesystem from the last archival snapshot (dump).

--
cinap

Re: [9fans] Thinkpad T61 Installation Experience

[Burton Samograd]

The defaults in my 9front installation were other, fscache and fsworm.  Does fscache == main and fsworm == dump?

-----Original Message-----
From: 9fans-bounces@9fans.net [mailto:9fans-bounces@9fans.net] On Behalf Of cinap_lenrek@gmx.de
Sent: Thursday, May 17, 2012 9:37 AM
To: 9fans@9fans.net
Subject: Re: [9fans] Thinkpad T61 Installation Experience

no. your user data is not in "other" filesystem. basicly there are 3 filesystems that cwfs exports after 9front installation.
"main", "dump" and "other". "main" is the primary file system that gets archived to the worm in daily intervals. the archival snapshots (dump) appear as directories in the read only "dump"
filesystem. "main" is your root filesystem.

once stuff is written to the worm, it never gets deleted. you can't discard dumps. they are there. forever.

the "other" filesystem is like a traditional unix filesystem.
its not dumped to worm and can be used kind of like scratch space.
we use it for the users /tmp directories.

you can do without a "other" fs. we added support for +t flags like there is in fossil, so you can just mark directories and files as temporary in the "main" filesystem so they dont get dumped to worm. (this works recursively on directories)

but requires a bigger fscache partition if you have lots of stuff flagged temporary. and you loose all your +t flagged data when recovering the filesystem from the last archival snapshot (dump).

--
cinap


This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page

Please visit http://www.markit.com/en/about/contact/contact-us.page? for contact information on our offices worldwide.

Re: [9fans] Thinkpad T61 Installation Experience

[erik quanstrom]

> you can do without a "other" fs. we added support for +t flags like
> there is in fossil, so you can just mark directories and files
> as temporary in the "main" filesystem so they dont get dumped
> to worm. (this works recursively on directories)
>
> but requires a bigger fscache partition if you have lots of stuff
> flagged temporary. and you loose all your +t flagged data when
> recovering the filesystem from the last archival snapshot (dump).

for that reason, i didn't add it.

- erik

Re: [9fans] Thinkpad T61 Installation Experience

[erik quanstrom]

On Thu May 17 11:46:03 EDT 2012, burton.samograd@markit.com wrote:
> The defaults in my 9front installation were other, fscache and fsworm.  Does fscache == main and fsworm == dump?
>

yes.

- erik

Re: [9fans] Thinkpad T61 Installation Experience

[cinap_lenrek]

no. lets look at a cwfs config.

filsys main c(/dev/sdC0/fscache)(/dev/sdC0/fsworm)
filsys dump o
filsys other (/dev/sdC0/fsother)

main is composed from fscache and fsworm. the cache contains the current
working set of blocks.

when data is requested and its not in the cache, it is read from
the worm and copied to the cache.

when you write new files, they are allocated in the cache. every day,
the filesystem runs a dump process wich copies the blocks that are in
the cache but not written to worm (dirty blocks) to the worm. and then
flags them as dumped so they can be replaced for other data in the cache.

its like a write cache to accumulate changes before they get written
to stable storage (worm).

only blocks that are new or got modified are dumped. this is like a
incremental backup. just that its not just backup, its the main
storage.

just read the fs paper erik linked. it explains it mutch better and
in more detail.

--
cinap

Re: [9fans] Thinkpad T61 Installation Experience

[David Romano]

cinap_lenrek@gmx.de wrote on Thu, May 17, 2012 at 08:37:09AM MST:
> you can do without a "other" fs. we added support for +t flags like
> there is in fossil, so you can just mark directories and files
> as temporary in the "main" filesystem so they dont get dumped
> to worm. (this works recursively on directories)
>
> but requires a bigger fscache partition if you have lots of stuff
> flagged temporary. and you loose all your +t flagged data when
> recovering the filesystem from the last archival snapshot (dump).
Considering what you wrote, I don't see any substantial benefit of supporting
+t flags in the "main" filesystem when you have "other" at your disposal.  Has
that discussion already taken place on IRC or another mailing list?

Why is +t preferable to having an "other" filesystem?  Is it merely so that
you don't have to be concerned with guessing an appropriate size for the
"other" fileystem?

--
David Romano .:. unobe@cpan.org

Re: [9fans] Thinkpad T61 Installation Experience

[erik quanstrom]

On Thu May 17 12:11:27 EDT 2012, unobe@cpan.org wrote:
> cinap_lenrek@gmx.de wrote on Thu, May 17, 2012 at 08:37:09AM MST:
> > you can do without a "other" fs. we added support for +t flags like
> > there is in fossil, so you can just mark directories and files
> > as temporary in the "main" filesystem so they dont get dumped
> > to worm. (this works recursively on directories)
> >
> > but requires a bigger fscache partition if you have lots of stuff
> > flagged temporary. and you loose all your +t flagged data when
> > recovering the filesystem from the last archival snapshot (dump).
> Considering what you wrote, I don't see any substantial benefit of supporting
> +t flags in the "main" filesystem when you have "other" at your disposal.  Has
> that discussion already taken place on IRC or another mailing list?
>
> Why is +t preferable to having an "other" filesystem?  Is it merely so that
> you don't have to be concerned with guessing an appropriate size for the
> "other" fileystem?

good question.  as i see it, the argument for +t is that the files remain
in the usual heirarchy.  the arguments against are a) you lose your stuff
if you "recover main" thus you can get into recovery situations with for-sure
data loss.  b) it is in the usual heirarchy, and thus one might
forget that it's got the +t bit set.  c)  it puts pressure on the cache, which
isn't prepared to be very large where as i've got a 1tb other.

- erik

[9fans] +t and bind (Was Re: Thinkpad T61 Installation Experience)

[David Romano]

erik quanstrom wrote on Thu, May 17, 2012 at 09:26:40AM MST:
> as i see it, the argument for +t is that the files remain in the usual
> heirarchy.
I think I understand.  So basically I don't need to worry about which
directories or files are bind(1)'d to others under the hierarchy, and the
hierarchy persists beyond reboot/restart.

I initially thought that the +t problem something that bind(1) could
definitely solve, i.e., bind a directory or file within a hierarchy to another
filesystem's directory or file. I think Cinap mentioned something about
binding each user's /tmp directory to a directory in the "other" filesystem.
I suppose that's the double-edged sword with having the dynamic capabilities
of bind(1).

If the problem is really one of persistence, is there any benefit to having
bind optionally record its last bind mapping for a particular path (within
each namespace or within each union directory)?  Or rather than modify
bind(1), just have a separate program that handles it?  Would that make the
entire process needlessly complex and raise other issues?

- David

--
David Romano .:. unobe@cpan.org

Re: [9fans] +t and bind (Was Re: Thinkpad T61 Installation Experience)

[Ethan Grammatikidis]

On Thu, 17 May 2012 12:43:15 -0700
David Romano <unobe@cpan.org> wrote:

> I suppose that's the double-edged sword with having the dynamic capabilities
> of bind(1).

In practice it's not much of a problem. /lib/namespace takes care of
the globally-persistant binds such as bind /$cputype/bin /bin and even
things like bind -c #e /env. $home/lib/profile takes care of per-user
binds including /tmp. These are the binds from my lib/profile which is
mostly a standard 9front one:

bind -b $home/bin/rc /bin
bind -b $home/bin/$cputype /bin
mount -qC /srv/cwfs /n/other other
bind -qc /n/other/usr/$user/tmp $home/tmp
bind -c $home/tmp /tmp
if(! syscall create /tmp/xxx 1 0666 >[2]/dev/null)
	ramfs	# in case we're running off a cd

Note the first 2 which are conventional Plan 9, you would expect those
to be there on any Plan 9 box. The two binds for tmp are no different.
(Yes, $home/tmp is normally bound to /tmp.)

[9fans] The creepy WORM. (was: Re: Thinkpad T61 Installation Experience)

[Nemo]

Because I noticed Ken's worm fs was being discussed in this thread, I thought
I might just drop here the man page for a new alternate file server that we wrote
for nix.

It's not yet ready for use (I'm using it, but it's still under testing, and the version
in the main nix tree is now out of date, btw; will send the new one soon).

But I thought it might be of interest to 9fans, if only to get comments.


     CREEPY(4)                                               CREEPY(4)

     NAME
          9pix, fmt, rip, arch - creepy file server and WORM archive

     SYNOPSIS
          creepy/9pix [ -DFLAGS ] [ -ra ] [ -A addr ] [ -S srv ] disk

          creepy/fmt [ -DFLAGS ] [ -wy ] disk

          creepy/rip [ -DFLAGS ] [ -a ] [ -c n ] [ -A addr ] [ -S srv
          ] disk

          creepy/arch [ -DFLAGS ] [ dir ]

     DESCRIPTION
          Creepy is a prototype file server for Nix. It maintains a
          mutable file tree with unix semantics, kept in main memory,
          served through 9P, see intro(5), and through IX.

          Creepy/9pix is the main file server program. It serves a
          file tree through 9P and IX.  The tree kept in memory is
          mutable. But frozen versions of the tree are written to
          disk, both upon request and also on a periodic basis, to
          survive power outages and other problems, and to be able to
          operate on trees that do not fit on main memory.  The
          tree(s) stored on disk are frozen and cannot be changed once
          written.

          By default the program listens for 9P in the standard TCP
          port and posts a connection that can be mounted at
          /srv/9pix.  Flags -A and -S may be used to specify an alter-
          nate network address and/or srv(3) file to post. Using these
          flags makes the program not to listen and not to post to
          srv(3) unless a flag indicates so.  Flag -r makes the pro-
          gram operate in read-only mode, and flag -a starts the pro-
          gram without requiring authentication to mount the file
          tree.

          The disk is organized as a log of blocks. When a new version
          of the tree must be written to disk, all blocks that changed
          are given disk addresses and are appended to the log. Once
          written, they are frozen.  If new changes are made to the
          tree, blocks are melted and forget their previous addresses:
          each time they are written again, they are assigned new
          ones.

          When the disk gets full, all reachable blocks are marked and
          all other blocks are considered available for growing the
          log (this is a description of semantics, not of the imple-
          mentation). Thus, the log is circular but jumps to the next
          available block each time it grows.  If, after the mark pro-
          cess, the disk is still full, the file system becomes read
          only but for removing files.

          Before using a disk it must be formatted using creepy/fmt.
          This initializes blocks used to store marks for the mark and
          sweep process and also initializes a super block and an
          empty root directory. Flag -y forces the format even if the
          disk seems to contain a fossil (4) or creepy (4) partition.
          Flag -w is used to format the partition for a WORM
          (described later) and not for a main file tree.

          Creepy/rip is the same file server program, but operates in
          WORM mode. In this case, no mark and sweep for free blocks
          will ever happen. Blocks are consumed from the disk until it
          becomes full.  The file tree served is always read-only.

          Operating the WORM to in administrative mode to add more
          trees or new versions of the archived trees does not require
          any protocol: it can be done using the standard file inter-
          face used to operate on any other tree, by mounting and
          changing it.

          An alternate mount specifier, wormwr, can be used to mount
          the tree in read-write mode, to update the archive.  Updat-
          ing the archive is performed by creating new trees with the
          conventional /treename/year/mmdd paths on the WORM. But note
          that such paths are not enforced by the program at all.
          Before updating a tree in the archive, for a new day, a con-
          trol request described later can be used to link the direc-
          tory for the previous version of the archive to the new one.
          After that, changes made to files would in effect copy on
          write all blocks affected, and refer to old ones when they
          did not change.

          Creepy/arch is a program started by creepy/9pix to archive
          snapshots of the tree into a directory provided by
          creepy/rip (or by any other file server).  The program is
          not expected to be run by users, and speaks a simple proto-
          col through its standard input: A block address is written
          and the block contents are read from it.  Usually, the stan-
          dard input is a pipe to creepy/9pix. The program takes the
          address of the root directory as kept on disk and then asks
          the file server program for block contents, to archive them
          into a mounted directory. Thus, the tree archived is always
          consistent because only consistent trees can be read from
          disk (the mutable file tree is kept in memory).

          The file tree provided by 9pix and rip has the following
          layout:
               /
               /root
               /cons
               /stats
          And, by convention, archives kept in the WORM are expected
          to have names like:
               /root/treename/2012/0425
               /root/treename/2012/0425.1
               /root/treename/2012/0426

          Using the main attach specifier yields the tree as just
          shown. Using an empty specifier, or root, or main/active
          yields the tree found at /root.  In creepy/rip the attach
          specifier wormwr yields the root of the tree in read-write
          mode.

          ∙    The root directory is never found on disk. It is a
               placeholder for the contained files.

          ∙    Cons is a synthesized file used as a console for file
               system administration, and it is not found on disk. It
               is still subject to file permissions, and coordinates
               concurrent access to the console by different users.
               The owner of the file server process is always allowed
               to access the console.

          ∙    Stats is another synthesized file used to report
               statistics.

          ∙    Root contains the actual  file tree. It corresponds to
               the file tree as seen at this moment by file system
               users. It's semantics are similar to those of a UNIX or
               Plan 9 file system.

          Users and groups can be added by creating and editing
          /root/users . See an example shown later.

          The console accepts the following commands:

          allow [uid]
               Lets uid bypass permissions, or show allowed users if
               none is given.

          disallow [uid]
               undoes the effect of the previous command for the given
               uid or for everyone if none is given.

          halt Halts the file system and terminates the processes.

          stats
               Reports usage statistics.

          sync Synchronizes the disk by writing a new version of the
               tree to the log.

          uname [uid]
               Reports information about user uid.

          users
               Prints the list of users.

          who  Reports the list of network addresses and users cur-
               rently using the file system.

          arch name hour [path]
               Schedules an archival into the WORM with the given tree
               name and at the given hour. By default, the WORM is
               expected at /n/rip in administrative mode. An optional
               path may be given to use a different directory.

          arch now
               archives the tree. The previous form must be used
               before to configure archival.

          arch none
               disables archival (this is the default).

          link src dst
               is used in the WORM to initialize a new archive by
               linking the one of the previous day to a new name,
               before updating the tree.

          ?    Prints the list of known commands. More than those
               describe here will be shown, mostly for debugging.

     EXAMPLES
          Format a partition and a WORM
               creepy/fmt /dev/sdC0/creepy
               creepy/fmt -w /dev/sdC0/rip

          Run the file system, mount it, initialize the user list with
          one from fossil(4), and populate it
               creepy/9pix /dev/sdC0/creepy main
               mount -c /srv/9pix /n/creepy
               cp /adm/users /n/creepy/root/users
               echo allow $user >/n/creepy/cons
               dircp /n/dist /n/creepy/root
          Run the worm (the previously file server would mount it if
          it finds its file posted in srv(3) and is asked to archive a
          tree.
               creepy/rip /dev/sdC0/rip

     SOURCE
          /sys/src/cmd/creepy

     SEE ALSO
          fossil(4), venti(8)

     BUGS
          Yes. But hopefully, with time and testing, less than those
          still waiting under the covers in other popular file server
          programs we use.

          Do not use this for your own files yet. It is experimental
          and still under testing.

Re: [9fans] The creepy WORM. (was: Re: Thinkpad T61 Installation Experience)

[Bakul Shah]

On Fri, 18 May 2012 23:13:54 +0200 Nemo <nemo@lsub.org>  wrote:
>           Creepy is a prototype file server for Nix. It maintains a
>           mutable file tree with unix semantics, kept in main memory,
>           served through 9P, see intro(5), and through IX.

Creepy? It has become a "creepy" word now!

>           Creepy/9pix is the main file server program. It serves a
>           file tree through 9P and IX.  The tree kept in memory is
>           mutable. But frozen versions of the tree are written to
>           disk, both upon request and also on a periodic basis, to
>           survive power outages and other problems, and to be able to
>           operate on trees that do not fit on main memory.  The
>           tree(s) stored on disk are frozen and cannot be changed once
>           written.

Just curious.
If the tree doesn't fit in memory, how do you decide who to
kick out? LRU? Sounds much like a cache fs. What does it buy
you over existing cache filesystems? Speaking more generally,
not just in the plan9 context.


>           The disk is organized as a log of blocks. When a new version
>           of the tree must be written to disk, all blocks that changed
>           are given disk addresses and are appended to the log. Once
>           written, they are frozen.  If new changes are made to the
>           tree, blocks are melted and forget their previous addresses:
>           each time they are written again, they are assigned new
>           ones.

I don't understand use of the words frozen & melted here.  How
is this different from how things work now? Something worse
than what venti or zfs do, which is to leave the old blocks
alone and allocate new space for new blocks.

>           When the disk gets full, all reachable blocks are marked and
>           all other blocks are considered available for growing the
>           log (this is a description of semantics, not of the imple-
>           mentation). Thus, the log is circular but jumps to the next
>           available block each time it grows.  If, after the mark pro-
>           cess, the disk is still full, the file system becomes read
>           only but for removing files.

Why does circularity matter? It would make more sense to allocate
new blocks for a given file near its existing blocks regardless of
writing order.

Why not just use venti or some existing FS underneath than
come up with a new disk format?

Sounds like a fun project but it would be nice to see the
rationale for it.

Thanks!

Re: [9fans] The creepy WORM. (was: Re: Thinkpad T61 Installation Experience)

[Francisco J Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 3665 bytes --]




using ipad keyboard. excuse any typos.

>> 
> 
> Just curious.
> If the tree doesn't fit in memory, how do you decide who to
> kick out? LRU? Sounds much like a cache fs. What does it buy
> you over existing cache filesystems? Speaking more generally,
> not just in the plan9 context.
> 
> 

lru for clean blocks. but you really have the tree you use in memory, all if it fits.
what it buys is simplicity, thus reliability, and speed.
instead of a single program doing everything, you have several trying to use
their memory and to avoid copying blocks in the main server.
plus, it's going to be modified to exploit the upcoming nix zero copy framework.


>>          The disk is organized as a log of blocks. When a new version
>>          of the tree must be written to disk, all blocks that changed
>>          are given disk addresses and are appended to the log. Once
>>          written, they are frozen.  If new changes are made to the
>>          tree, blocks are melted and forget their previous addresses:
>>          each time they are written again, they are assigned new
>>          ones.
> 
> I don't understand use of the words frozen & melted here.  How
> is this different from how things work now? Something worse
> than what venti or zfs do, which is to leave the old blocks
> alone and allocate new space for new blocks.
> 

it's not cow. you reuse the memory of a frozen block instead of copying.
you just melt it and reuse it. 

all this is in memory. cow happens only on the disk, but you don't wait for that.
that's the main difference wrt others.



>>          When the disk gets full, all reachable blocks are marked and
>>          all other blocks are considered available for growing the
>>          log (this is a description of semantics, not of the imple-
>>          mentation). Thus, the log is circular but jumps to the next
>>          available block each time it grows.  If, after the mark pro-
>>          cess, the disk is still full, the file system becomes read
>>          only but for removing files.
> 
> Why does circularity matter? It would make more sense to allocate
> new blocks for a given file near its existing blocks regardless of
> writing order.
> 

for simplicity, I removed most of the fanciest things I had before in place in
previous versions that could be a source of bugs. there are no ref. counters,
for example. it's designed to operate on
main memory, and it seems it does well even though the disk algorithms are
naive.


> Why not just use venti or some existing FS underneath than
> come up with a new disk format?
> 

to avoid complexity, latency, and bugs.

it's now a set of tools, you can archive creepy into venti if you want, or archive
fossil into a creepy rip (it's the same program, actually).

for archival, you are going to use a pipe, and not a tcp connection.

you have a program half the size, or 1/4 depending on how you wc.

it takes half the time fossil takes in the silly tests I made, and you can understand
the code the first time you read it, which is not trivial with the others, but for Ken's.

last, it's expected not to give you corrupted files despite power failures, which we
had in both fossil and venti (I'm not saying its their fault, our environment is bumpy).

that was the motivation, exploiting large main memories and keeping things simple
and reliable. Time will tell if we managed to achieve that or not :)

sorry I wrote in Sioux this time. its been a long day here :)

> Sounds like a fun project but it would be nice to see the
> rationale for it.
> 
> Thanks!

[-- Attachment #2: Type: text/html, Size: 6233 bytes --]

Re: [9fans] The creepy WORM. (was: Re: Thinkpad T61 Installation Experience)

[Bakul Shah]

On Sat, 19 May 2012 00:45:58 +0200 Francisco J Ballesteros <nemo@lsub.org>  wrote:

> > Just curious.
> > If the tree doesn't fit in memory, how do you decide who to
> > kick out? LRU? Sounds much like a cache fs. What does it buy
> > you over existing cache filesystems? Speaking more generally,
> > not just in the plan9 context.
>
> lru for clean blocks. but you really have the tree you use in memory, all if
> it fits.  what it buys is simplicity, thus reliability, and speed.
> instead of a single program doing everything, you have several trying to use
> their memory and to avoid copying blocks in the main server.
> plus, it's going to be modified to exploit the upcoming nix zero copy framework.

This last point is more or less independent of the FS (as long
as an io buffer is page aligned and io count is a multiple of
page size).

> it's not cow. you reuse the memory of a frozen block instead of copying.
> you just melt it and reuse it.

> all this is in memory. cow happens only on the disk, but you don't wait for that.
> that's the main difference wrt others.

How often would you flush to disk? You still need to worry about the order
of writing metadata.

> >>          When the disk gets full, all reachable blocks are marked and
> >>          all other blocks are considered available for growing the
> >>          log (this is a description of semantics, not of the imple-
> >>          mentation). Thus, the log is circular but jumps to the next
> >>          available block each time it grows.  If, after the mark pro-
> >>          cess, the disk is still full, the file system becomes read
> >>          only but for removing files.
> >
> > Why does circularity matter? It would make more sense to allocate
> > new blocks for a given file near its existing blocks regardless of
> > writing order.
>
> for simplicity, I removed most of the fanciest things I had before in place in
> previous versions that could be a source of bugs. there are no ref. counters,
> for example. it's designed to operate on
> main memory, and it seems it does well even though the disk algorithms are
> naive.

You do have to keep track of free disk blocks. On disk. So a linked list
would require you visit every freed block.

> > Why not just use venti or some existing FS underneath than
> > come up with a new disk format?
>
> to avoid complexity, latency, and bugs.

I think an incore FS the easy case but you will have to face
the issues of corner/boundary cases, various error conditions
and efficiency when dealing with real disks. These things are
what introduce complexity and bugs. "Soft updates" in FFS took
quite a while shake out bugs.  zfs took a long time.  Hammer
fs of DragonFly took a while. Pretty much every FS design has
taken a while to be rock solid.  Far longer than the original
estimates of the designers I think.

> that was the motivation, exploiting large main memories and keeping things
> simple and reliable. Time will tell if we managed to achieve that or not :)

Ah. I have been looking at SBCs with memories in the 128MB to
512MB range! Can't afford an incore FS!

But even if there is gigabytes of memory why would I want to
dedicate a lot of it to a filesystem? Most of the FS data is
going to be "cold" most of the time. When you suddenly need
lots of memory for some memory intensive computation, it may
be too late to evacuate the memory of your FS data. But
memory is just a file cache, this data can be thrown away any
time if you need more space.  And by making sure the cache
holds a bounded amount of dirty data, you lose no more than
that amount of data in case of a crash.

> sorry I wrote in Sioux this time. its been a long day here :)

Thanks for taking the time. Always nice to see yet another
attempt at getting this right :-)

Re: [9fans] The creepy WORM. (was: Re: Thinkpad T61 Installation Experience)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 254 bytes --]

those restrictions are not necessary

On 20 May 2012 04:13, Bakul Shah <bakul@bitblocks.com> wrote:

> This last point is more or less independent of the FS (as long
> as an io buffer is page aligned and io count is a multiple of
> page size).
>

[-- Attachment #2: Type: text/html, Size: 544 bytes --]

Re: [9fans] The creepy WORM. (was: Re: Thinkpad T61 Installation Experience)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 248 bytes --]

we don't compute on file servers

On 20 May 2012 04:13, Bakul Shah <bakul@bitblocks.com> wrote:

> When you suddenly need
> lots of memory for some memory intensive computation, it may
> be too late to evacuate the memory of your FS data
>

[-- Attachment #2: Type: text/html, Size: 514 bytes --]

Re: [9fans] The creepy WORM. (was: Re: Thinkpad T61 Installation Experience)

[Francisco J Ballesteros]

On May 20, 2012, at 5:13 AM, Bakul Shah <bakul@bitblocks.com> wrote:

> 
> How often would you flush to disk? You still need to worry about the order
> of writing metadata.
> 

that's the nice thing. it's so simple I don't have to worry about order. you write new
blocks and, once all of them reached the disk without errors, you write a new super with
the address of a new root. if you fail before the super is written, you have the old tree,
otherwise, you get the new one. the super has two copies of its data, in case you fail
in the middle of writing it, if they don't match, you use the oldest one.

The tmr proc writes new versions of the tree on a periodic basis and also if the
number of dirty (of memory addressed, actually) blocks exceeds some value.


> You do have to keep track of free disk blocks. On disk. So a linked list
> would require you visit every freed block.
> 


There's no linked list either :)
There's a mark per block, an epoch number, so you have one block with marks
for each block group. all blocks given addresses on disk use the current value for the
mark or epoch. when you want to collect more free blocks, you traverse the tree and update
the mark for blocks. After that, you increment the value for the mark that is used to recognize
free blocks.

Of course you could fail at any time, and, again, if you do that before writing the new
super the only thing that happens is that you'll have to mark again the blocks (you
prune the mark process when you find that the block visited already has the correct mark
value).

This was actually the code I had in place to double check that the previous implementation
for free block management was correct, but I noticed that it was both doing the job, and 
not disturbing normal operation in the file system, so I removed the management code and
declared this debug check the actual algorithm.


> I think an incore FS the easy case but you will have to face
> the issues of corner/boundary cases, various error conditions
> and efficiency when dealing with real disks. These things are
> what introduce complexity and bugs. "Soft updates" in FFS took
> quite a while shake out bugs.  zfs took a long time.  Hammer
> fs of DragonFly took a while. Pretty much every FS design has
> taken a while to be rock solid.  Far longer than the original
> estimates of the designers I think.
> 


Yes, that's why I improved it mostly by removing features and simplifying algorithms
instead of using clever ones. It was not easy to do that, it had like three or four rewrites.
Funny it was a lot easier to write the first, much more complex, version of it.

There are no soft
updates now, because the log makes that unneeded. And the complex part of
log management, which is reclaiming unused blocks, is also gone because of the
naive, yet effective, algorithm used now.

But you are right. I spent most of the time fixing problems with disks that were full or
had faults injected at the worst times. The operation in non boundary cases was always
fine, even with the fancier implementation I used before.

Regarding memory and processors, the code is aggressive and tries to use everything
because the machine will be devoted just to serve files.