Re: seldom crashes on Dell E6330 with 12-CURRENT

From: Mark Millard <markmi_at_dsl-only.net>
Date: Mon, 25 Jul 2016 23:30:09 -0700
On 2016-Jul-25, at 10:50 PM, Matthias Apitz <guru_at_unixarea.de> wrote:
> 
> El día Monday, July 25, 2016 a las 05:00:59PM -0700, Mark Millard escribió:
> 
>> Matthias Apitz guru at unixarea.de wrote on Mon Jul 25 16:10:52 UTC 2016 :
>> 
>>> On Monday, 25 July 2016 17:11:23 CEST, Eric van Gyzen <vangyzen at FreeBSD.org> wrote: > 
>>>> What file system are you using? 
>>> UFS; I followed the good instructions about new SSD disk configuration; that's why I now have swap as plain file :-( 
>> 
>> Unfortunately see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048 :
>> 
>> 11.0-CURRENT -r293227 (and others) arm (rpi2/BeagleBone Black) amd64 etc: swapfile usage hangs; swap partition works .
>> 
>> As far as I know it still applies for the problems that can occur for plain-file based swap files. The list of comments covers more than just armv6 as having example failures.
>> 
> 
> Thanks for the pointer to the bug issue. I remembered, that I created
> the swap file as a so called sparse file (dd ... bs=1m seek=8192 count=0) and
> this is still visible with du(1):
> 
> # du -sh /usr/swap01 ; ls -lh /usr/swap01
> 95M	/usr/swap01
> -rw-------  1 root  wheel   8,0G 25 jul.  08:19 /usr/swap01
> 
> I have now unmounted the swap and re-created it with real blocks:
> 
> # swapoff -a
> swapoff: removing /dev/md99 as swap device
> 
> # dd if=/dev/zero of=/usr/swap01 bs=1m count=8192
> 8192+0 records in
> 8192+0 records out
> 8589934592 bytes transferred in 43.594277 secs (197042712 bytes/sec)
> # du -sh /usr/swap01 ; ls -lh /usr/swap01
> 8,0G	/usr/swap01
> -rw-------  1 root  wheel   8,0G 26 jul.  07:24 /usr/swap01
> 
> I will first give this a try. If the crash rehappens, I will move it to
> a real freebsd-swap partition.

FYI: All my uses and testing of swap files used such a dd command to populate the file with blocks. I've never even tried a sparse file for such a thing.

My experience indicates that this will not remove the problem if the swap file is in a file system on a partition with other file system activity (at least in the same file system?).

The only type of context that I've had a swap file work over lots of use is when I used a whole partition containing just one UFS file system that only had the swap file added after the UFS file system was created.  In other words: About the closest thing to being a swap partition that is still file based. I've only done this on TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64. I tried it for them because TRIM was possible in the context: it was a SATA context with SSDs, not a USB context. (I did this during my very first FreeBSD experiments. I only learned later of problems with other variations.)

My other, later contexts do not have TRIM as possible (for example, USB) and so I did not do that. It is these that I had troubles with and later switched to using a swap partition instead.

[I will not have access to the powerpc's for weeks.]

> 
> While saying 'crash', I now remember that in the two cases which I named
> 'hard locked', the system was still alive in the sense of echoing typed
> chars, it was only impossible to start new commands or login on another
> console. This points too in the direction of a disk access or swap problem.
> 
> Thanks
> 
> 	matthias


===
Mark Millard
markmi at dsl-only.net
Received on Tue Jul 26 2016 - 04:30:13 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:07 UTC