Comment 6 for bug 1525300

Apologies, please disregard part of my previous comment about 5.6 behavior different in first scenario. I just tested on a wrong, very big table, so just the INSERT..SELECT was too long.

Correct test ended up with similar abort on 5.6.37:

2017-10-19 19:13:51 7fc63404f700 InnoDB: Error: Write to file ./test/j2.ibd failed at offset 19922944.
InnoDB: 1048576 bytes should have been written, only 0 were written.
InnoDB: Operating system error number 28.
InnoDB: Check that your OS and file system support files of this size.
InnoDB: Check also that the disk is not full or a disk quota exceeded.
InnoDB: Error number 28 means 'No space left on device'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
2017-10-19 19:13:51 28725 [ERROR] /usr/sbin/mysqld: The table 'j2' is full
2017-10-19 19:13:51 28725 [ERROR] Slave SQL: Could not execute Write_rows event on table test.j2; The table 'j2' is full, Error_code: 1114; handler error HA_ERR_RECORD_FILE_FULL; the event's master log FIRST, end_log_pos 8156999, Error_code: 1114
2017-10-19 19:13:51 28725 [Warning] WSREP: RBR event 1001 Write_rows apply warning: 135, 698196
2017-10-19 19:13:53 28725 [Note] WSREP: 0.0 (percona2): State transfer to 2.0 (percona1) complete.
2017-10-19 19:13:53 28725 [Note] WSREP: Member 0.0 (percona2) synced with group.
2017-10-19 19:13:58 28725 [Warning] WSREP: Failed to apply app buffer: seqno: 698196, status: 1
         at galera/src/trx_handle.cpp:apply():351
Retrying 2th time
2017-10-19 19:14:03 28725 [ERROR] /usr/sbin/mysqld: The table 'j2' is full
2017-10-19 19:14:03 28725 [ERROR] Slave SQL: Could not execute Write_rows event on table test.j2; The table 'j2' is full, Error_code: 1114; handler error HA_ERR_RECORD_FILE_FULL; the event's master log FIRST, end_log_pos 8156999, Error_code: 1114
2017-10-19 19:14:03 28725 [Warning] WSREP: RBR event 1001 Write_rows apply warning: 135, 698196
2017-10-19 19:14:08 28725 [Warning] WSREP: Failed to apply app buffer: seqno: 698196, status: 1
         at galera/src/trx_handle.cpp:apply():351
Retrying 3th time
2017-10-19 19:14:13 28725 [ERROR] /usr/sbin/mysqld: The table 'j2' is full
2017-10-19 19:14:13 28725 [ERROR] Slave SQL: Could not execute Write_rows event on table test.j2; The table 'j2' is full, Error_code: 1114; handler error HA_ERR_RECORD_FILE_FULL; the event's master log FIRST, end_log_pos 8156999, Error_code: 1114
2017-10-19 19:14:13 28725 [Warning] WSREP: RBR event 1001 Write_rows apply warning: 135, 698196
2017-10-19 19:14:20 28725 [Warning] WSREP: Failed to apply app buffer: seqno: 698196, status: 1
         at galera/src/trx_handle.cpp:apply():351
Retrying 4th time
2017-10-19 19:14:26 28725 [ERROR] /usr/sbin/mysqld: The table 'j2' is full
2017-10-19 19:14:26 28725 [ERROR] Slave SQL: Could not execute Write_rows event on table test.j2; The table 'j2' is full, Error_code: 1114; handler error HA_ERR_RECORD_FILE_FULL; the event's master log FIRST, end_log_pos 8156999, Error_code: 1114
2017-10-19 19:14:26 28725 [Warning] WSREP: RBR event 1001 Write_rows apply warning: 135, 698196
2017-10-19 19:14:32 28725 [ERROR] WSREP: Failed to apply trx: source: 27d14989-b4d5-11e7-ad16-be9fc86a2280 version: 3 local: 0 state: APPLYING flags: 1 conn_id: 7 trx_id: 944060 seqnos (l: 14, g: 698196, s: 698195, d: 698195, ts: 18251585865656442)
2017-10-19 19:14:32 28725 [ERROR] WSREP: Failed to apply trx 698196 4 times
2017-10-19 19:14:32 28725 [ERROR] WSREP: Node consistency compromized, aborting...
2017-10-19 19:14:32 28725 [Note] WSREP: Closing send monitor...
2017-10-19 19:14:32 28725 [Note] WSREP: Closed send monitor.

So this node was killed as well, and two others continue to operate just fine.

This leaves only situation with binary logs full as a problem, and I tend to second opinion that this is a "Won't fix" case here or at least it could be a feature request to introduce setting that would abort such node.