> >>> That is, the code called by io_submit() >>> (file_operations::write_iter, it seems to be called today) can kick >>> off this operation and have it continue from where it left off. >> >> This is a problem that people have tried to solve in the past (e.g. >> syslets, etc) where the thread executes until it has to block, and >> then it's handled off to a worker thread/syslet to block and the >> main process returns with EIOCBQUEUED. > > > Yes, I remember that. > >> Basically, you're asking for a real AIO infrastructure to >> beintroduced into the kernel, and I think that's beyond what us XFS >> guys can do... > > > Sure you can, Dave. In fact you feel an irresistible urge to do it. What is that? Are you that anxious for the Star Wars premiere that you are trying your very own jedi mind tricks?? > I do now. What's the unicode for a crying face? > >> Hence if you are seeing delays in transactions (e.g. timestamp updates) >> it's entirely possible that things will get much better if you >> remove the discard mount option. It's much better from a performance >> perspective to use the fstrim command every so often - fstrim issues >> discard operations in the context of the fstrim process - it does >> not interact with the transaction subsystem at all. >> >> > > All right. On the other hand we have to know when to issue it. That would > be when nn% of the disk area have been rewritten. Is there some counter I > can poll every minute or so for this? Not doing the fstrim in time would > cause the disk performance to tank. Note, as I said, that while this is a really good general recommendation from down under, that was not likely to have had any effect in the current trace - that disk does not support discard, and I am assuming the mount option becomes a noop in this case. > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
