Solved How to work around ZFS update delay on file contents?

Buck

Buck

I'm trying to program html and PHP pages and use an external file manager that works over SSH to edit files directly on the server. Then I refresh a page in a browser to visualize the changes. However, the web root is on a ZFS partition and there's a noticeable several-seconds delay, which is annoying. Is there any way to tell ZFS to treat a specific folder/dataset in a different way so that the changes are always immediate or at least get the highest priority?
 
I think this is more likely caching in your web server software. When you close() a file on any file system, it should immediately be visible to other applications to open() in the updated state. (Note it may not yet be on physical storage at that point, but that’s not what you are asking.)
 
No, I've checked with cat. There is a delay. For some seconds cat also shows me an old version. I've actually read about it somewhere, that this behavior is normally expected from ZFS, but cannot remember the details.
 
I would side with Eric. I am working remotely on FreeBSD/ZFS webservers for years and never have such problem. If you see old content with cat, maybe your editor didn't finished transfer yet? Assuming you are using something downloading/uploading files in background over SFTP/SCP.
 
This could well be the SSH connection buffering! I have seen similar issues with shared files over SSHFS mounts.
You can check if this is the case by logging on to the server, then open a text editor like nano or vi and edit the files in place, then save them.
Load the page in your browser - is the change visible immediately? If not, then something must be cached or buffered for some seconds either in the File Manager you mentioned or in PHP/Apache or your browser.
You can also use "cat" on the file inside your SSH session to validate that the ZFS returns the changes immediately.

There is nothing in ZFS that would delay your changes after you save and close the file. All changes are in real time.
 
Async writes (the default behavior) on ZFS typically go through a "txg" (Transaction Group). It is periodic, I think default period is around 5 secs (I could be/may be wrong on the interval). That could explain part of the delay.
Synch writes are pushed through as quickly as possible.
I'm not sure if the dataset has a property that says "sync writes" ( I think there is just don't have it at hand) similar to a UFS filesystem mounted "synch".

Don't forget that changes to a file exist in buffers before they actually get written to a physical device, so a write followed immediately by a read may pull from system buffers not from the physical device.

Above is just my opinions and does not contradict anything anyone else has said.

A bit of DuckDuckGo:
zfs set sync=always dataset

means do synch writes for that data set for metadata and data.
 
You can also try to run /bin/sh and there this for i in `seq 20` ; do echo $i >> file && cat file && echo '========================' ; done ; - it will append sequence starting from 1 to file and immediately show content of file.
 
Also, you can try the same setup with another server that uses EXT4 or UFS instead of ZFS. I assume you would see the same behavior if the server is configured identically.
 
mer said:
Async writes (the default behavior) on ZFS typically go through a "txg" (Transaction Group). It is periodic, I think default period is around 5 secs (I could be/may be wrong on the interval). That could explain part of the delay.
Synch writes are pushed through as quickly as possible.
I'm not sure if the dataset has a property that says "sync writes" ( I think there is just don't have it at hand) similar to a UFS filesystem mounted "synch".

Don't forget that changes to a file exist in buffers before they actually get written to a physical device, so a write followed immediately by a read may pull from system buffers not from the physical device.

Above is just my opinions and does not contradict anything anyone else has said.
Click to expand...

In this case it should not matter if the data is actually written to the hardware. Even if it were only bufferred in memory, ZFS would still return the latest written data in real-time, right?
 
mer said:
Async writes (the default behavior) on ZFS typically go through a "txg" (Transaction Group). It is periodic, I think default period is around 5 secs (I could be/may be wrong on the interval). That could explain part of the delay.
Click to expand...

This does not delay when other programs can see the changes to the filesystem. This is strictly a statement of how often non-SYNC-ed state synchronized to disk.
 
Just stop and think of the chaos that would ensue if programs couldn’t rely on a written file existing (as far as the system’s open()/read() API is concerned; commit to non-volitile is a separate layer) in its freshly-written state, with no way to know when it is available.

So yes, look long and hard at your tool that is “allowing editing of a remote file”. My money is on how/when this tool updates the remote file.
 
You must log in or register to reply here.
Back
Top