Re: [9fans] copying fossil filesystem to a bigger disk

Sorry, I was wrong : I am running plan9/fossil on a 1TB WD Caviar disk: WD1002FBYS, however, this is not what you wanted, sorry. ++pac On Thu, Oct 6, 2011 at 9:35 AM, Peter A. Cejchan wrote: > i use WD Caviar > Greenmodel > *WD20EARS (2TB

Re: [9fans] copying fossil filesystem to a bigger disk

> fossil/conf /dev/sdE0/fossil > fossil.conf > fossil/conf -w /dev/sdE0/fossil fossil.conf This was exactly what I needed. Thank you! My migration from old to new drive is now complete.

Re: [9fans] copying fossil filesystem to a bigger disk

> Does fossil store the device name somewhere on the disk? (The drive > was sdE1 when I formatted it.) How can I change it to sdE0? The configuration is stored at the 127kB offset of Fossil file system. Read configuration: fossil/conf /dev/sdE0/fossil > fossil.conf Write configuration: fossil/

Re: [9fans] copying fossil filesystem to a bigger disk

> Now let's see if it boots. Almost there. I took out the old drive and made the new one sdE0. It started booting, until: fossil(#S/sdE0/fossil)... fsOpen: can't find /dev/sdE1/fossil ... panic Does fossil store the device name somewhere on the disk? (The drive was sdE1 when I formatted it.) How

Re: [9fans] copying fossil filesystem to a bigger disk

snarf-paste error. the command was: su# disk/mkfs -s /n/old -d /n/new -U -r <{echo +}

Re: [9fans] copying fossil filesystem to a bigger disk

> you're not the first person to make this mistake, so i should > have remembered this problem.  sorry. Please don't apologize. You are the one guiding the blind. > you need to mount both new and old afresh in /n/ and copy > using your destination as /n/new and source as /n/old.  using > / as you

Re: [9fans] copying fossil filesystem to a bigger disk

> su# disk/mkfs -a -s / <{echo +} > arch > processing /fd/7 > mkfs: /fd/7:1: can't open //dev/consctl: '//dev/consctl' permission denied > mkfs: /fd/7:1: can't open //dev/kprint: '//dev/kprint' device or > object already in use > > I guess it wasn't the brightest idea, because the arch file grew m

Re: [9fans] copying fossil filesystem to a bigger disk

No error, no crash. Just some files/dirs are not copied to new destination. du -s gives different number on linux vs. ext2srv/plan9 native./ Also, du -a | wc -l differ. I was not able to identify any system in which files/ dirs do not appear on ext2srv. First, i thought that dirs with > 120 files,

Re: [9fans] copying fossil filesystem to a bigger disk

> that's a good question.  if you just want to copy everything, i use the shell > idiom >        disk/mkfs <{echo +} I ran this in /usr/bootes/ as bootes: su# disk/mkfs -a -s / <{echo +} > arch processing /fd/7 mkfs: /fd/7:1: can't open //dev/consctl: '//dev/consctl' permission denied mkfs:

Re: [9fans] copying fossil filesystem to a bigger disk

On Sun Oct 9 22:34:04 EDT 2011, slash.9f...@gmail.com wrote: > > i think disk/mkfs is nearly idea for this, and isn't very dangerous.  since > > your > > new fossil will start empty, you can't overwrite anything in the old fs. > > How do I generate the proto file? Do I have to go through an arch

Re: [9fans] copying fossil filesystem to a bigger disk

> i think disk/mkfs is nearly idea for this, and isn't very dangerous.  since > your > new fossil will start empty, you can't overwrite anything in the old fs. How do I generate the proto file? Do I have to go through an archive? Thank you for your patience.

Re: [9fans] copying fossil filesystem to a bigger disk

> I would like to copy 9fat, nvram and fossil from the old drive to the > new drive. 9fat is no problem. But how about nvram? Can I just use dd? sure. > As for fossil, I have not been able to figure out how to do this. > replica(1) looks like has the capability to do this, but I don't want > to e

Re: [9fans] copying fossil filesystem to a bigger disk

Out of interest - what is the problem with ext2srv with too many files/subdirs? what error does it give, does it crash? -Steve

Re: [9fans] copying fossil filesystem to a bigger disk

>> i use WD Caviar Green model WD20EARS (2TB SATA II) without any problems. I > >> installed from erik's 9atom.iso > > > Did you toggle any jumpers on the drive? I finally gave up and returned > it. > > No. No jumpers at all are inserted. It worked just out-of-the-box. I had first to switch to "Tr

Re: [9fans] copying fossil filesystem to a bigger disk

On Thu, Oct 6, 2011 at 3:35 AM, Peter A. Cejchan wrote: > i use WD Caviar Green model WD20EARS (2TB SATA II) without any problems. I > installed from erik's 9atom.iso Did you toggle any jumpers on the drive? I finally gave up and returned it. A new day, a new disk (with 512 byte sectors). I ins

Re: [9fans] copying fossil filesystem to a bigger disk

i use WD Caviar Greenmodel *WD20EARS (2TB SATA II*) without any problems. I installed from erik's 9atom.iso it is quite silent, but I have no idea how to measure its speed :-( ++pac On Tue, Oct 4, 2011 at 1:07 AM, slash wrote: > > the way

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

> > 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

Re: [9fans] copying fossil filesystem to a bigger disk

> 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

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

> i think the attached program ought to work. Doing i/o to random blocks, aren't you mostly measuring seek time?

Re: [9fans] copying fossil filesystem to a bigger disk

> 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

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

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 (

Re: [9fans] copying fossil filesystem to a bigger disk

> 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.

Re: [9fans] copying fossil filesystem to a bigger disk

> 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

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

> 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.

Re: [9fans] copying fossil filesystem to a bigger disk

> 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

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

> 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.

Re: [9fans] copying fossil filesystem to a bigger disk

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.

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

> 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.

Re: [9fans] copying fossil filesystem to a bigger disk

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. >

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

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

Re: [9fans] copying fossil filesystem to a bigger disk

On Mon Oct 3 19:08:49 EDT 2011, slash.9f...@gmail.com wrote: > > the way to interpret this information is you may use 512 > > byte sectors if you really want to suffer terrible performance > > (usually 1/3 the normal performance for reasonablly random > > workloads.) > > That doesn't sound tempti

Re: [9fans] copying fossil filesystem to a bigger disk

> the way to interpret this information is you may use 512 > byte sectors if you really want to suffer terrible performance > (usually 1/3 the normal performance for reasonablly random > workloads.) That doesn't sound tempting at all. I am still within Amazon's return window. Can anyone recommend

Re: [9fans] copying fossil filesystem to a bigger disk

On Mon Oct 3 19:08:49 EDT 2011, slash.9f...@gmail.com wrote: > > the way to interpret this information is you may use 512 > > byte sectors if you really want to suffer terrible performance > > (usually 1/3 the normal performance for reasonablly random > > workloads.) > > That doesn't sound tempti

Re: [9fans] copying fossil filesystem to a bigger disk

i forgot the interesting part of the program output word 106 6003 [valid=1] multiple log/phys? 1 log/phys 8 logical sector size 0 [valid=0] the logical sector size is by default 512, so the fact the logical sector size is invalid means it's 512. - erik

Re: [9fans] copying fossil filesystem to a bigger disk

since i don't have one of these drives, i wrote a little program to dig into the ident block. a small aside. ata disks have two sector sizes. (groan.) there's the logical sector size and the physical sector size. by default they are both 512. the ears drive sets the set logical sector size to 5

Re: [9fans] copying fossil filesystem to a bigger disk

>        echo 'identify device' | 8.atazz -r /dev/sdE0 > /tmp/somefile > > would be better Here goes. sdE0.out Description: Binary data sdE1.out Description: Binary data

Re: [9fans] copying fossil filesystem to a bigger disk

On Sat Oct 1 06:37:52 EDT 2011, slash.9f...@gmail.com wrote: > > if you (slash) could just grab the atazz binary > > (ftp://ftp.quanstro.net/other/8.atazz) > > and send me the output of > >        echo 'identify device' | 8.atazz -r >[2=] /dev/sdE0 > /tmp/somefile > > that would be great.  thank

Re: [9fans] copying fossil filesystem to a bigger disk

> if you (slash) could just grab the atazz binary > (ftp://ftp.quanstro.net/other/8.atazz) > and send me the output of >        echo 'identify device' | 8.atazz -r >[2=] /dev/sdE0 > /tmp/somefile > that would be great.  thanks! Here you go. Again, sdE0 is the old drive, sdE1 is the new one. slas

Re: [9fans] copying fossil filesystem to a bigger disk

On Fri, 30 Sep 2011 10:44:01 +0100 Charles Forsyth wrote: > it's impressive that by 2011 we are unable to drive disks in as > straightforward > a manner as in the 1970s. better still, there are several competing miserable > standards (and i'm not even including USB). Not to be too depressive, b

Re: [9fans] copying fossil filesystem to a bigger disk

On Fri Sep 30 04:55:43 EDT 2011, 9f...@hamnavoe.com wrote: > > I have a WD10EARS which lies about its sector size > > Some further information: I'm using the sdata driver rather than > sdiahci because my motherboard doesn't support ahci. This may be why > I'm seeing the disk as having 512-byte se

Re: [9fans] copying fossil filesystem to a bigger disk

On Fri Sep 30 05:37:57 EDT 2011, fors...@terzarima.net wrote: > it's impressive that by 2011 we are unable to drive disks in as > straightforward > a manner as in the 1970s. better still, there are several competing miserable > standards (and i'm not even including USB). this is one case where i

Re: [9fans] copying fossil filesystem to a bigger disk

it's impressive that by 2011 we are unable to drive disks in as straightforward a manner as in the 1970s. better still, there are several competing miserable standards (and i'm not even including USB).

Re: [9fans] copying fossil filesystem to a bigger disk

> I have a WD10EARS which lies about its sector size Some further information: I'm using the sdata driver rather than sdiahci because my motherboard doesn't support ahci. This may be why I'm seeing the disk as having 512-byte sectors not 4096. You could try telling your BIOS to use the disk in A

Re: [9fans] copying fossil filesystem to a bigger disk

> inquiry WDC WD20EARS-00MVWB0 > ... > The new drive is completely blank. It has 4096 byte sector size, and > disk/mbr fails. > > su# disk/mbr -m /386/mbr /dev/sdE1/data > mbr: secsize 4096 invalid Interesting. I have a WD10EARS which lies about its sector size - it reports 512 although it's rea

Re: [9fans] copying fossil filesystem to a bigger disk

> Do you use Fossil with or without Venti? > There is many way to do it. > > Without Venti, you could use replica(1) to copy your file system > from the old Fossil to the new Fossil. Fossil without Venti. Work has kept me busy but now I finally managed to attach the new drive to the system. Plan9

Re: [9fans] copying fossil filesystem to a bigger disk

> With Venti, you could use venti/rdarena to export arenas from the > old Venti, then import them to the new Venti with venti/wrarena. > Finally, format the Fossil partition from the last Fossil score. Honestly I would advise against this, I did it but it was really quite painful. When I upgraded

Re: [9fans] copying fossil filesystem to a bigger disk

The advice I got a couple of years ago was to go for 7200RPM SATA3 disks, make sure they are branded as enterprise quality (worth paying for) and buy them from different manufacturers. Then mirror the disks and hopefully one disk will die before the other and thus you get some long term reliabalit

Re: [9fans] copying fossil filesystem to a bigger disk

> I am about to upgrade the disk on my cpu/disk server to a bigger one, > and I want to maintain all the data. What is the most elegant way to > do this? The new disk is blank. Do you use Fossil with or without Venti? There is many way to do it. Without Venti, you could use replica(1) to copy you

[9fans] copying fossil filesystem to a bigger disk

I am about to upgrade the disk on my cpu/disk server to a bigger one, and I want to maintain all the data. What is the most elegant way to do this? The new disk is blank.