On Fri, Apr 14, 2017 at 01:33:36PM -0700, Ngie Cooper (yaneurabeya) 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’ > > ?
No, something like: % swapinfo Device 1K-blocks Used Avail Capacity /dev/ada0p2 33554432 0 33554432 0% /dev/ada1p2 33554432 0 33554432 0% Total 67108864 0 67108864 0% > > 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. _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
