From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001
From: Nicolas Vigier <boklm@mageia.org>
Date: Sun, 14 Apr 2013 13:46:12 +0000
Subject: Add zarb MLs html archives

---
 .../attachments/20121119/bb9785c8/attachment-0001.html | 18 ++++++++++++++++++
 .../attachments/20121119/bb9785c8/attachment.html      | 18 ++++++++++++++++++
 2 files changed, 36 insertions(+)
 create mode 100644 zarb-ml/mageia-dev/attachments/20121119/bb9785c8/attachment-0001.html
 create mode 100644 zarb-ml/mageia-dev/attachments/20121119/bb9785c8/attachment.html

(limited to 'zarb-ml/mageia-dev/attachments/20121119/bb9785c8')

diff --git a/zarb-ml/mageia-dev/attachments/20121119/bb9785c8/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20121119/bb9785c8/attachment-0001.html
new file mode 100644
index 000000000..666d2c8d5
--- /dev/null
+++ b/zarb-ml/mageia-dev/attachments/20121119/bb9785c8/attachment-0001.html
@@ -0,0 +1,18 @@
+<br><br><div class="gmail_quote">On Mon, Nov 19, 2012 at 9:39 AM, Colin Guthrie <span dir="ltr">&lt;<a href="mailto:mageia@colin.guthr.ie" target="_blank">mageia@colin.guthr.ie</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+
+Hi,<br>
+<br>
+For many, many years, I&#39;ve always done a umount -l  on stale NFS mounts<br>
+(e.g. when resuming in a different location to suspending).<br>
+<br>
+This has always worked, but very recently (i.e. in the last couple<br>
+weeks) this has stopped working.<br>
+<br>
+Anyone know what could be up?<br>
+<br>
+Blino&#39;s change to nfs-utils doesn&#39;t look like a problem.<br>
+<br>
+The call that&#39;s stalling things is stat(), but this never used to be a<br>
+problem with lazy umounts in the past (not sure if it&#39;s just stat()<br>
+that&#39;s now blocking at a kernel level or of some userspace code now<br>
+calls it when in the past it did not?<br></blockquote><div><br></div><div>If your nfs mount is dead I would expect stat to hang, so I guess it wasn&#39;t called in the past. </div></div>
diff --git a/zarb-ml/mageia-dev/attachments/20121119/bb9785c8/attachment.html b/zarb-ml/mageia-dev/attachments/20121119/bb9785c8/attachment.html
new file mode 100644
index 000000000..666d2c8d5
--- /dev/null
+++ b/zarb-ml/mageia-dev/attachments/20121119/bb9785c8/attachment.html
@@ -0,0 +1,18 @@
+<br><br><div class="gmail_quote">On Mon, Nov 19, 2012 at 9:39 AM, Colin Guthrie <span dir="ltr">&lt;<a href="mailto:mageia@colin.guthr.ie" target="_blank">mageia@colin.guthr.ie</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+
+Hi,<br>
+<br>
+For many, many years, I&#39;ve always done a umount -l  on stale NFS mounts<br>
+(e.g. when resuming in a different location to suspending).<br>
+<br>
+This has always worked, but very recently (i.e. in the last couple<br>
+weeks) this has stopped working.<br>
+<br>
+Anyone know what could be up?<br>
+<br>
+Blino&#39;s change to nfs-utils doesn&#39;t look like a problem.<br>
+<br>
+The call that&#39;s stalling things is stat(), but this never used to be a<br>
+problem with lazy umounts in the past (not sure if it&#39;s just stat()<br>
+that&#39;s now blocking at a kernel level or of some userspace code now<br>
+calls it when in the past it did not?<br></blockquote><div><br></div><div>If your nfs mount is dead I would expect stat to hang, so I guess it wasn&#39;t called in the past. </div></div>
-- 
cgit v1.2.1