(11:20:35 PM) riteshh: I read this below from one of the DAX pdf - "For xfs-dax, we'd need to use logdev=/dev/[btt-partition]"
(11:20:35 PM) riteshh: Could you please tell why this limitation only with XFS and not with ext4?
(11:20:35 PM) riteshh: Also does that mean it cannot guarantee filesystem consistency across clean reboots as well?
(11:20:35 PM) riteshh: sorry I am not well versed with XFS code in general, but if you could tell where to look into code, I can go and check. But some info is needed.
(11:20:44 PM) sandeen: sorry that "maintainer does his job!" is so exciting ;)
(11:21:30 PM) sandeen: "one of the DAX pdf ?"
(11:22:13 PM) riteshh: sorry my bad - https://events.static.linuxfound.org/sites/events/files/slides/vault-btt_0.pdf
(11:22:29 PM) riteshh: slide 33
(11:25:13 PM) riteshh: It says -
(11:25:13 PM) riteshh: XFS relies on journal updates being sector atomic – For xfs-dax, we'd need to use logdev=/dev/[btt-partition]
(11:25:13 PM) riteshh: But I needed more info around this, so I asked. Also a comparison w.r.t ext4 could help me understand better.
(11:25:47 PM) djwong: ext4 has the same problem, they just don't know that
(11:26:31 PM) riteshh: :P
(11:26:38 PM) djwong: jbd2 and the xfs log both require that a disk can write a whole sector or not
(11:27:24 PM) riteshh: but that's a block device filesystem limitation in general no?
(11:27:24 PM) riteshh: any IO writes is assumed to be sector atomic, no?
(11:27:31 PM) djwong: right
(11:27:55 PM) djwong: but pmem isn't sector atomic (without BTT, at least)
(11:28:29 PM) djwong: so iirc the log/journal both write their commit records as a single "atomic" sector-sized record
(11:29:35 PM) riteshh: yes - that's what I thought too. that commit record must be sector atomic. but since it says ext4 does not have the problem but only XFS has it - so I asked.
(11:32:58 PM) djwong: <shrug> that was from 2015
(11:33:14 PM) djwong: you could ask vishal if it's still true
(11:33:48 PM) djwong: hah, -rc1 finally
(11:34:18 PM) riteshh: ok. will try and check with him.
(11:34:21 PM) riteshh: thanks
(11:36:48 PM) ***vishal appears
(11:37:04 PM) djwong: but you've the right instinct that all the disk filesystems are probably going to need BTT if they want atomic sector writes
(11:37:34 PM) vishal: djwong: I thought the xfs v5 layout(?) mitigates that via checksummed journal entries?
(11:38:24 PM) djwong: it mitigates it, but if the write tears, the crc will be wrong and -EFSCORRUPTED
(11:39:00 PM) djwong: so you won't be running along with a garbage fs at least
(11:39:03 PM) djwong: but it'll still generate support calls
(11:39:38 PM) vishal: Ah I see, so if it was on a btt logdev, then you might lose some of the transactions, but no fs corruption
(11:41:26 PM) djwong: <shrug> if btt actually provides atomic "sector" updates then logdev=/dev/bttX should be sufficient to avoid corrupt looking log blocks
(11:42:57 PM) vishal: riteshh: the slides don't mention anything about ext4, do they? I agree with djwong, ext4/jbd2 probably need the same approach
(11:43:26 PM) djwong: they don't (you wrote the slides ;))
(11:43:46 PM) anticw: djwong: (this probably already happens) ... but years ago when i needed to log and couldn't trust writers were atomic i put a checksum at the start and the end of the block
(11:43:49 PM) vishal: I knew they looked familiar ;)
(11:43:58 PM) anticw: it didn't prevent short writes, but it let me detect them
(11:44:49 PM) vishal: (/me just trying to wrap head around what riteshh's ask was)
(11:44:52 PM) riteshh: yes - my bad. It does not mention ext4. I assumed "No news is Good news" :)