Re: Any way to "passive commit" to RAM without syncing ?

[Swift Griggs <swiftgriggs%gmail.com@localhost>]

On Tue, 8 Mar 2016, Hal Murray wrote:
> I had a setup for a while to keep working log files in RAM.  I have 
> forgotten the details.

I have done something like that with XFS under Linux. The thing is, WAPBL 
logging doesn't seem to have an option (or perhaps I'm just ignorant of 
it) for doing logging to a separate block device. Ie.. if I could point to 
a MFS device for that, I think that would be pretty close to what I want. 
At the very least it'd be a lot like ZFS's ZIL, theoretically.

I've also wondered if I'd be setting myself up for disaster by going into 
the kernel code and stretching the flush timers for UFS way way out. I'm 
looking in /usr/src/sys/ufs/ffs at ffs_vnops.c and ffs_vfsops.c for any 
kind of timers or tunables, but wasn't finding much. I found where fsync() 
ffs_full_fsync() get defined, but nothing jumped out at me. Looking at 
/usr/src/sys/ufs/ufs there seems to be more relevant code. The problem is 
that I can see several places where I'm going to shoot myself in the foot 
trying to delay or defer a write. Not having done my Ph.D thesis in file 
systems, I find I'm a bit intimidated (but I'll try it anyhow, what the 
hell).

So, the bottom line is that it looks like the folks who've suggested some 
kind of work-in-RAM and periodically copy-to-physical approach are onto 
the only working setup like this.

It seems like if there is some general way to perform asynchronous 
"logging" to a RAM-based device, it's not easy. I'm assuming this because 
so few implementations exist. The one that comes to mind right away is the 
DRBD async log shipping mode which is a for $$$ only killer-feature in 
DRBD.  In the best case scenario, it can theoretically give you full speed 
access to a local block device, while still allowing you to have a 
mirrored block device in another state with 80ms latency or something. All 
you have to do have a big enough buffer and enough bandwidth to handle any 
backlog that accumulates.

That approach seems like one that could be generalized into a cache-layer 
for any file system. Sprite did that but only for it's native file system, 
Cachefs for Solaris does that, too. RAM is now pretty cheap and the volume 
is big enough that I can operate out of my 2-3 Gb home directory and if 
that was fully cached, it still wouldn't matter on my systems with 16-24 
Gb of RAM. It's just an interesting thought.

-Swift