[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