Oracle suggests to have the external journal on a low latency device.
The default location for an XFS journal is on the same block device as the data. As synchronous metadata writes to the journal must complete successfully before any associated data writes can start, such a layout can lead to disk contention for the typical workload pattern on a database server. To overcome this problem, you can place the journal on a separate physical device with a low-latency I/O path.
The device with the lowest latency is a RAM disk. But is it possible to use a RAM disk?
I ask because it seems to be necessary to specify the logdev
option during the creation of the XFS filesystem. Any structure written to the logdev during XFS creation will be lost after a reboot, if I put it on a RAM disk.
I know the RAM disk will not help against power loose. But my use-case is a SSD connected by USB. I just want some protection against pulling the USB cable.
Out of the box it does not seem to work.
Create 100 MB RAM-Disk in /dev/ram0
.
# modprobe brd rd_size=102400 max_part=1 rd_nr=1
Create XFS with external log.
# mkfs.xfs -l logdev=/dev/ram0 /dev/sdc1
Mount filesystem.
# mkdir /media/xfs
# mount -t xfs -o logdev=/dev/ram0 /dev/sdc1 /media/xfs
Unmount.
# umount /media/xfs
Remove RAM disk.
# rmmod brd
Recreate RAM disk.
# modprobe brd rd_size=102400 max_part=1 rd_nr=1
Remount filesystem.
# mount -t xfs -o logdev=/dev/ram0 /dev/sdc1 /media/xfs
mount: /media/xfs: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error.
But when I repair the filesystem, I can mount it.
# xfs_repair -l /dev/ram0 /dev/sdc1
[...]
Phase 2 - using external log on /dev/ram0
- zero log...
totally zeroed log
[...]
Maximum metadata LSN (1:2880) is ahead of log (0:0).
Format log to cycle 4.
done
# mount -t xfs -o logdev=/dev/ram0 /dev/sdc1 /media/xfs
Now I am wondering, if it is a good idea to do so.
wsync
option instead? – frostschutz Jun 22 '22 at 09:48