[Vm-dev] FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux
Alistair Grant
akgrant0710 at gmail.com
Mon Jul 2 17:58:11 UTC 2018
Hi Markus,
On Mon, 2 Jul 2018 at 19:07, Markus Fritsche <mfritsche at reauktion.de> wrote:
>
> flushing the handle before truncate turns the test green indeed.
Great!
> truncate does reopen (close, open) - maybe the flush should be put in
> reopen?
The FilePlugin primitives are used by multiple classes and from Pharo
7 BinaryFileStream is the main interface to files. While FileHandle
reopens the file, BinaryFileStream doesn't. Then Squeak has its own
usage. So I think that putting the flush in to the truncate primitive
is the right thing to do. Let me know if you disagree.
> How is flushing handles handled in glue-code generally?
I'm not sure I understand your question. There's a primitive for
flushing open files (primitiveFileFlush(), which calls sqFileFlush()).
> https://dynamic.reauktion.de/~mfritsche/ptvm.tar.zst is a kvm based vm
> (hard disc, xml vm config) (user pharo, password pharo) that shows the
> problem - at least on my hardware.
I'm not a kvm user, and the descriptions match my understanding well
enough. Combined with your tests, I think we've got sufficient
justification for the change.
Assuming no other objections are raised before-hand: If you can
submit a PR, great! If not, let me know and I'll make the change
(although it could take a few weeks - limited time and other changes I
want to see incorporated).
Thanks,
Alistair
> On 02.07.2018 17:27, Alistair Grant wrote:
> >
> > Hi Markus,
> >
> > On Mon, 2 Jul 2018 at 13:05, Markus Fritsche <mfritsche at reauktion.de> wrote:
> >> interesting - below is a summary of my installation. I had this issue way back when (vm-beginners, 04/09/2014) with a complete different software setup (last time I've checked I didn't register as a bogon source on the meter, in fact, I take pride in being a clueon source at work).
> >>
> >> mfritsche at hawking:~/Pharo$ uname -a
> >> Linux hawking 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> >>
> >> mfritsche at hawking:~/Pharo$ cat /proc/cpuinfo | head -n 5
> >> processor : 0
> >> vendor_id : GenuineIntel
> >> cpu family : 6
> >> model : 60
> >> model name : Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz
> >>
> >> mfritsche at hawking:~/Pharo$ ./pharo --version
> >> 5.0-201805090836 Wed May 9 08:54:40 UTC 2018 gcc 4.8 [Production Spur 64-bit VM]
> >> CoInterpreter VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018
> >> StackToRegisterMappingCogit VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018
> >> VM: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> >> Date: Wed May 9 10:36:12 2018 CommitHash: 334be97
> >> Plugins: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> >> Linux travis-job-5ab63a26-b2a8-4841-93ff-7aa5dc4e571e 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> >> plugin path: /home/mfritsche/Pharo/pharo-vm/lib/pharo/5.0-201805090836 [default: /home/mfritsche/Pharo/pharo-vm/lib/pharo/5.0-201805090836/]
> >>
> >> mfritsche at hawking:~/Pharo$ ls -alh /lib/x86_64-linux-gnu/libc-2.27.so
> >> -rwxr-xr-x 1 root root 2,0M Apr 16 22:14 /lib/x86_64-linux-gnu/libc-2.27.so
> > I tried creating a btrfs ram disk in a docker image (I don't have the
> > btrfs tools installed on my machine) and still didn't reproduce the
> > problem (I do remember sqlite having problems with btrfs, and vaguely
> > remember flushing and/or truncate being involved).
> >
> > Since you mention flushing being documented as required before
> > truncating, can you try modifying the test and seeing if that makes a
> > difference?
> >
> > FileSystemHandleTest>>testTruncate
> > | out |
> > out := #(1 2 3 4 5) asByteArray.
> > handle at: 1 write: out startingAt: 1 count: 5.
> > handle flush.
> > handle truncateTo: 3.
> > self assert: handle size = 3
> >
> >
> > For the record:
> >
> > $ uname -a
> > Linux alistair-xps13 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May
> > 30 11:18:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> >
> >
> > $ ./pharo --version
> > 5.0-201805090836 Wed May 9 08:54:40 UTC 2018 gcc 4.8 [Production
> > Spur 64-bit VM]
> > CoInterpreter VMMaker.oscog-eem.2380 uuid:
> > c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018
> > StackToRegisterMappingCogit VMMaker.oscog-eem.2380 uuid:
> > c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018
> > VM: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> > Date: Wed May 9 10:36:12 2018 CommitHash: 334be97
> > Plugins: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> > Linux travis-job-5ab63a26-b2a8-4841-93ff-7aa5dc4e571e
> > 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017
> > x86_64 x86_64 x86_64 GNU/Linux
> > plugin path: /mnt/p7/pharo-vm/lib/pharo/5.0-201805090836 [default:
> > /mnt/p7/pharo-vm/lib/pharo/5.0-201805090836/]
> >
> >
> > Cheers,
> > Alistair
> >
> >
> >
> >> On 02.07.2018 11:57, Alistair Grant wrote:
> >>
> >> Hi Markus,
> >>
> >> It looks like it is something else then. I'm away from my PC now, but running the tests in a tmpfs ram disk have worked in the past. I'm using SSDs. I'll check again when I have access.
> >>
> >> Cheers,
> >> Alistair
> >> (on phone, thus the short reply)
> >>
> >> On Mon., 2 Jul. 2018, 09:56 Markus Fritsche, <mfritsche at reauktion.de> wrote:
> >>>
> >>> Hi Alistair,
> >>>
> >>> I created a file-based ext4fs in my ram-based /tmp/ and executed the
> >>> FileHandleTest starting the image out of that file system - the test
> >>> still fails.
> >>>
> >>> Are you having your file system on rotating rust or in
> >>> electron-arresting transistors (like me)?
> >>>
> >>>
> >>> Best regards,
> >>>
> >>> Markus
> >>>
> >>>
> >>> On 02.07.2018 09:26, Alistair Grant wrote:
> >>>> Hi Markus,
> >>>>
> >>>> The test passes in my Pharo 7 64 bit image with Ubuntu 16.04 on ZFS.
> >>>>
> >>>> Are you able to test on a file system other than btrfs? Or anything
> >>>> else that might be different in your environment?
> >>>>
> >>>> P.S. I'm not saying that FilePlugin shouldn't be changed, I haven't
> >>>> looked at it, but it would be nice to reproduce the issue first.
> >>>>
> >>>> Thanks,
> >>>> Alistair
>
>
More information about the Vm-dev
mailing list