[OmniOS-discuss] Pliant/Sandisk SSD ZIL

[Richard Elling]

On Feb 27, 2014, at 6:25 AM, Jim Klimov <jimklimov at cos.ru> wrote:

> On 2014-02-23 06:14, Richard Elling wrote:
>> On Feb 18, 2014, at 10:40 AM, Jim Klimov <jimklimov at cos.ru> wrote:
>> 
>>> On 2014-02-18 08:05, Richard Elling wrote:
>>>> Fortunately, most real workloads are not tar -x.
>>> 
>>> Oh, alas, on build farms they are. And the hordes of files produced
>>> as a result of "make" are not far behind. Oh, well, often they are
>>> behind - and subsequent accesses fail for a few seconds, just until
>>> something syncs down the pipe and back to the client. So the typical
>>> mantra is "gmake -j -k all; gmake all" for producing as many objects
>>> as we can first, and then cleaning up the mess sequentially :)
>> 
>> For build farms, why do you care about NFS sync writes? This is the
>> canonical case for sync=disabled, because there is no unique data.
>>  — richard
> 
> Interesting suggestion :)
> 
> In one example I have, the builds from several nodes are done in
> subdirectories of a user's home directory, as well as edition of
> some files (sources, recipes/makefiles) in the process. And being
> a home, it is sync'ed per defaults.
> 
> But I might investigate if dedicating a sub-dataset without sync
> would help and won't cause races (i.e. edit a file on one host,
> initiate a build quickly on another, and compile the obsolete
> version which was cached by NFS client), so thanks :)
> 
> I hope, NFS cached-data syncs and locks, and ZFS write-syncs are
> not very related in this case (i.e. zfs sync=disabled does not
> influence co-ordination of NFS data between hosts), right?

Right. The file system is consistent. The NFS sync is for the case when
the server reboots. As long as your server isn't rebooting, everything
should be consistent (assuming the clients are configured appropriately)
 -- richard