> On Apr 14, 2017, at 13:43, Larry Rosenman <l...@lerctr.org> wrote: > > On 4/14/17, 3:39 PM, "Ngie Cooper (yaneurabeya)" > <owner-svn-src-...@freebsd.org on behalf of yaneurab...@gmail.com> wrote: > >> On Apr 14, 2017, at 13:37, Larry Rosenman <l...@lerctr.org> wrote: >> >> On 4/14/17, 3:33 PM, "Ngie Cooper (yaneurabeya)" <yaneurab...@gmail.com> >> wrote: >> >>> On Apr 14, 2017, at 13:26, Larry Rosenman <l...@lerctr.org> wrote: >>> >>> On 4/14/17, 3:19 PM, "Ngie Cooper (yaneurabeya)" >>> <owner-svn-src-...@freebsd.org on behalf of yaneurab...@gmail.com> wrote: >>> >>>> On Apr 14, 2017, at 13:14, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote: >>>> >>>> On Fri, Apr 14, 2017 at 01:49:51PM -0600, Alan Somers wrote: >>>> >>>>> On Fri, Apr 14, 2017 at 1:41 PM, Ngie Cooper <n...@freebsd.org> wrote: >>>>>> Author: ngie >>>>>> Date: Fri Apr 14 19:41:48 2017 >>>>>> New Revision: 316938 >>>>>> URL: https://svnweb.freebsd.org/changeset/base/316938 >>>>>> >>>>>> Log: >>>>>> savecore: fix space calculation with respect to `minfree` in >>>>>> check_space(..) >>>>>> >>>>>> - Use strtoll(3) instead of atoi(3), because atoi(3) limits the >>>>>> representable data to INT_MAX. Check the values received from >>>>>> strtoll(3), trimming trailing whitespace off the end to maintain >>>>>> POLA. >>>>>> - Use `KiB` instead of `kB` when describing free space, total space, >>>>>> etc. I am now fully aware of `KiB` being the IEC standard for 1024 >>>>>> bytes and `kB` being the IEC standard for 1000 bytes. >>>>>> - Store available number of KiB in `available` so it can be more >>>>>> easily queried and compared to ensure that there are enough KiB to >>>>>> store the dump image on disk. >>>>>> - Print out the reserved space on disk, per `minfree`, so end-users >>>>>> can troubleshoot why check_space(..) is reporting that there isn't >>>>>> enough free space. >>>>>> >>>>>> MFC after: 7 weeks >>>>>> Reviewed by: Anton Rang <r...@acm.com> (earlier diff), cem (earlier >>>>>> diff) >>>>>> Tested with: positive/negative cases (see review); make tinderbox >>>>>> Sponsored by: Dell EMC Isilon >>>>>> Differential Revision: D10379 >>>>> >>>>> The free space calculation is still uselessly conservative, because it >>>>> doesn't account for the fact that core dumps will always be either >>>>> spare or compressed. The result is that savecore will frequently >>>>> refuse to save corefiles even when there's plenty of space. I >>>>> proposed removing the space check altogether in >>>>> https://reviews.freebsd.org/D2587. However, I agreed to wait until >>>>> after the compressed core dump feature was merged, because then mostly >>>>> accurate space checks will be possible. AFAIK the compressed core >>>>> dump feature still hasn't been finished. >>>> >>>> Is posible (in the future) to use multiple swaps (on multiple disks) >>>> for save core dumps? >>> >>> Multiple swap devices is already handled by savecore(8), if one uses >>> fstab(5) or dumpon(8). Otherwise, you must invoke savecore(8) on individual >>> devices. >>> >>> As far as saving to multiple disks is concerned, I would hope that one is >>> using a redundancy capable filesystem (zfs) or RAID-like technology >>> (gmirror, graid, LSI Fusion’s RAID product line) to stripe and/or mirror >>> the data across multiple disks. >> >> … >> >>> How do I use multiple devices to have the system dump on all of my swap? I >>> got a message about not enough space, but there (I think) was enough >>> between multiple drives…. >> >> Something like: >> >> - Create a zpool >> - Mount zpool to /crashdumps >> - Change dumpdir in /etc/rc.conf to be /crashdumps, e.g., echo >> ‘dumpdir=/crashdumps’ >> >> ? >> HTH, >> -Ngie >> >> PS The issue with lack of space might be the issue that Alan brought up >> earlier with compressed dumps and overly conservative free space checks, or >> it might be the fact that dumpdir (default: /var/crash) is full. >> >> >> I was talking about the actual crashdump to swap by the system. /var/crash >> has 10T of space (my root pool). > > If your memory is bigger than your swap, you’re unfortunately not able to > save the mini dump if the size of the saved pages exceed the space on swap. I > think this is where markj’s compressed dumps feature will come in handy. > Thanks! > -Ngie > > > Yeah, I have the following: > borg.lerctr.org /home/ler $ swapctl -l > Device: 1024-blocks Used: > /dev/mfid0p3 8388608 0 > /dev/mfid1p3 8388608 0 > /dev/mfid2p3 8388608 0 > /dev/mfid3p3 8388608 0 > /dev/mfid4p3 8388608 0 > /dev/mfid5p3 8388608 0 > borg.lerctr.org /home/ler $ sysctl hw.physmem > hw.physmem: 137368682496 > borg.lerctr.org /home/ler $ > > SO 6 8G partitions (48G), but the dump is larger than 8G.
Yup, that’s not going to work. Since you’re using mfi(4), I’d try creating another 48GB large RAID-0 volume to help deal with that issue. Cheers, -Ngie
signature.asc
Description: Message signed with OpenPGP using GPGMail
