Is the NFS over network code upstream ? On 10/25/13, Hugo Mills <h...@carfax.org.uk> wrote: > On Fri, Oct 25, 2013 at 04:35:46PM +0600, Roman Mamedov wrote: >> On Thu, 24 Oct 2013 23:52:01 +0300 >> Timofey Titovets <nefelim...@gmail.com> wrote: >> >> > Hello, i suggest temporary solution to use swap file under btrfs. >> > I test it, and it work good. >> > >> > I invent simple the way, how create and using swap file, just see >> > following sh code: >> > >> > swapfile=$(losetup -f) #free loop device >> > truncate -s 8G /swap #create 8G sparse swap file >> > losetup $swapfile /swap #mount file to loop >> > mkswap $swapfile >> > swapon $swapfile >> > >> > i just adding this to rc.local and this work good. >> > May be, add it to btrfs Wiki as temporary solution to using swap file? >> >> I always thought Btrfs does not allow swap files on purpose, because it is >> not >> deadlock-proof when used in the swapping context. > > It's more that the current swap interface is based on device+block > list, and if you balance a filesystem, the blocks for a file move -- > but there's no way of telling the swap code to cope with that. > >> Imagine you try swapping out pages to free up some memory, and in the >> process >> Btrfs needs to allocate some memory to actually perform the write, the >> kernel >> says "Sure, but for that we need to swap out some more pages..." You see >> where >> that goes. >> >> Same issue is possible with swap on other complex filesystems an example >> being networked ones like NFS and SMB/CIFS. > > The network filesystems have a similar problem as btrfs -- they > don't export devices, and you don't get direct access to the low-level > blocks under the FS, so the swap code can't deal with it. > > That said, there's been a lot of work recently on getting > swap-over-NFS to work properly -- effectively giving a new interface > for the swap code that doesn't rely on direct mapping to device > blocks. That new interface gives us the minimal external > infrastructure necessary to consider doing swapfiles on btrfs. > >> It might work for some time (or even work 99% of time), but you still may >> be >> endangering your system to a possibility of a lock-up, and certainly >> adding >> that to any Wiki/FAQ/website as "the solution" might not be the best >> choice. > > The deadlock situation is dealt with by adding a flag to the memory > allocator in the swap-critical paths, which says you're not allowed to > swap anything when you make the allocation. That at least allows the > memory allocation to fail (hopefully gracefully) without deadlocking. > I suspect that this is also part of the swap-on-NFS work -- adding > that flag everywhere necessary. > > Hugo. > > -- > === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === > PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk > --- He's playing Schubert. I think Schubert is losing. --- >
-- Karim Allah Ahmed. LinkedIn <http://eg.linkedin.com/pub/karim-allah-ahmed/13/829/550/> -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
