Re: async vs. sync

["jehan.procaccia" <jehan.procaccia@int-evry.fr>]

Yes, I did made a note on this long thread to resume it. it is mainly in 
french but mix a lot of english and captures a also in english so I 
might be easy for you to read it .
Here it is ;

http://www.int-evry.fr/mci/user/procacci/Doc/nfs.html

check principaly from chapter 8  to the end
thanks everyone for your help.

Alex Mccoll wrote:

>Hi Jehan,
>I've been following your discussion with Neil Brown, thank you
>for your insights! I'm roughly in the same situation, and it's
>been very helpful for me to find your thread!
>Say, did you figure out how to create the journal on a seperate
>device?  If you have any notes on that, could you send them
>my way?
>
>Thanks, in advance,
>Alex.
>
>
>On Tue, 23 Nov 2004, jehan procaccia wrote:
>
>  
>
>>Date: Tue, 23 Nov 2004 22:46:44 +0100
>>From: jehan procaccia <jehan.procaccia@int-evry.fr>
>>To: "Lever, Charles" <Charles.Lever@netapp.com>
>>Cc: nfs@lists.sourceforge.net
>>Subject: Re: [NFS] async vs. sync
>>
>>Lever, Charles wrote:
>>
>>    
>>
>>>>This is what I expect in term of performances . I will continue my
>>>>requests on the DEll/EMC hotline , but maybe the security of
>>>>that AX100
>>>>storage Processor (raid5, spare disk, double fiber attachement, UPS)
>>>>allows me to use async export mode in such a case ?
>>>>
>>>>
>>>>        
>>>>
>>>the "async" export option changes the behavior of the NFS server
>>>daemons, not of the underlying local file system or storage subsystem.
>>>the problem is that changes made by clients will remain in your NFS
>>>server's memory and not get flushed onto permanent storage.
>>>
>>>so, i really don't think the storage subsystem will have any effect on
>>>the safety of your data before the data reaches permanent storage.  as
>>>someone else pointed out earlier, the solution is to use battery-backed
>>>main memory when using "async" (prestoserve for solaris?).
>>>
>>>as trond said, if your users and backup facilities can tolerate the loss
>>>of data during a crash, then it is perfectly fine to use "async."  most
>>>don't, however.
>>>
>>>btw, it is fairly well understood that RAID-5 and NFS servers don't mix
>>>well.  RAID-5's weakest point is that it doesn't handle small random
>>>writes very well, and that's exactly what is required of it when
>>>handling NFS traffic that consists mostly of metadata changes (file
>>>creates, deletes, and so on).  neil explained clearly how to make the
>>>best use of a RAID-5 with NFS: do your local file system journaling
>>>somewhere else.
>>>
>>>
>>>      
>>>
>>No, not yet, but  if it is safer and increase performances maybe I
>>should do it !
>>
>>Perhaps it's not the place to talk about ext3 here, but if someone on
>>the list did already put their journal on a separate device, please
>>confirm me those points:
>> From what I read on man mkefs for ext3 FS I can create a journal on a
>>separate FS :
>>mke2fs -O journal_dev external-journal
>>creates the journal FS, on which device ? -> internal scsi drive of my
>>server or better placed on the dell/EMC SP ?
>>
>>mke2fs -J device=/dev/external-journal /dev/emcpower
>>Format the FS and use the external journal just create above, but what is the recommended size of the
>>external journal ?  when journal is internal it is said  the size of the journal must be at least 1024 filesystem blocks
>>(in my case blocks a 4K size) so journal is at least 4 Mb, but should it be bigger ?
>>
>>Finally, can I "externalize" an already internal journal from production FS  (convert journal from inside to outside without reformating the FS ) ?
>>
>>thanks.
>>
>>
>>    
>>
>>>when trying your workload locally on the NFS server, realize that there
>>>are some optimizations that local file systems make, like caching and
>>>coalescing metadata updates, that the NFS protocol does not allow.  this
>>>affects especially workloads with lots of metadata change operations,
>>>because the NFS protocol requires each metadata update to reside on
>>>permanent storage before the NFS server replies to the client,
>>>effectively serializing the workload with storage activity.
>>>
>>>
>>>      
>>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://productguide.itmanagersjournal.com/
>>_______________________________________________
>>NFS maillist  -  NFS@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/nfs
>>
>>    
>>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs