Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON) corrupts files extracted to NFS

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR port-evbmips/48564; it has been noted by 
GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON)
 corrupts files extracted to NFS
Date: Mon, 2 Jun 2014 01:47:00 +0000

 On Tue, Apr 29, 2014 at 10:10:00PM +0000, John D. Baker wrote:
  >  > A plain 'cp src dst' where "dst" is on NFS works fine.  I did not explore
  >  > output redirection, which I should do when I next have opportunity.  So
  >  > far, all other writes to NFS-resident files (such as with 'vi') work.
  >  
  >  File writes via output redirection fail in the same way as extraction with
  >  'tar'.  File copy with 'cp' works.
 
 That's strange, since nfs shouldn't be able to tell the difference. I
 guess it must have something to do with the block size being used for
 writing. In which case it would be helpful if you could dig that out
 (use ktrace) and see if there are any patterns.
 
  >  Editing a sufficiently large file with 'vi' and writing will produce
  >  error messages about an unknown file format and claims that the file is
  >  truncated, but later inspection indicates no obvious damage.  (I was
  >  editing my "~/.ssh/known_hosts" file at the time.  Subsequent use of the
  >  file by the ssh client succeeded--writing this very message over that
  >  session.)
 
 This might be easier to track down, if it's repeatable.
 
  >  In the "changing too many things at once" department, these most recent
  >  observations were made on a release built with "HAVE_GCC=48".  So there's
  >  further potential complication.
 
 Most likely it's a pmap/cache control issue.
 
 Which reminds me: if you don't have the fixes for PR 46890 yet, try
 pulling that and see if it helps.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost