From: "Björn JACKE" <bj@SerNet.DE>
To: Jeff Layton <jlayton@samba.org>
Cc: Steve French <sfrench@samba.org>,
"Stefan \(metze\) Metzmacher" <metze@samba.org>,
linux-cifs@vger.kernel.org, samba-technical@lists.samba.org,
linux-kernel@vger.kernel.org,
Dave Chiluk <dave.chiluk@canonical.com>,
Dave Chiluk <chiluk@canonical.com>
Subject: Re: [PATCH] CIFS: Decrease reconnection delay when switching nics
Date: Thu, 28 Feb 2013 23:54:13 +0100 [thread overview]
Message-ID: <E1UBCMh-00FRaK-CC@intern.SerNet.DE> (raw)
In-Reply-To: <20130228072637.3b71a4f7@corrin.poochiereds.net>
On 2013-02-28 at 07:26 -0800 Jeff Layton sent off:
> NTFS doesn't support sparse files, so the OS has to zero-fill up to the
> point where you're writing. That can take a looooong time on slow
> storage (minutes even).
but you are talking about FAT here, right? NTFS does support sparse files if
the sparse bit has been explicitly been set on it. Bit even if the sparse bit
is not set filling a file with zeros by writing after a seek long beyond the
end of the file is very fast because NTFS supports that feature what Unix
filesystems like xfs call extents.
If writing beyond the end of a file is really slow via cifs vfs in the test
case against a ntfs volume then I wonder if that operation is being really done
optimally over the wire. ntfs really isn't that bad with handling this kind of
files.
Cheers
Björn
WARNING: multiple messages have this Message-ID (diff)
From: "Björn JACKE" <bj@SerNet.DE>
To: Jeff Layton <jlayton@samba.org>
Cc: Dave Chiluk <dave.chiluk@canonical.com>,
Steve French <sfrench@samba.org>,
linux-cifs@vger.kernel.org, samba-technical@lists.samba.org,
linux-kernel@vger.kernel.org,
"Stefan (metze) Metzmacher" <metze@samba.org>,
Dave Chiluk <chiluk@canonical.com>
Subject: Re: [PATCH] CIFS: Decrease reconnection delay when switching nics
Date: Thu, 28 Feb 2013 23:54:13 +0100 [thread overview]
Message-ID: <E1UBCMh-00FRaK-CC@intern.SerNet.DE> (raw)
In-Reply-To: <20130228072637.3b71a4f7@corrin.poochiereds.net>
On 2013-02-28 at 07:26 -0800 Jeff Layton sent off:
> NTFS doesn't support sparse files, so the OS has to zero-fill up to the
> point where you're writing. That can take a looooong time on slow
> storage (minutes even).
but you are talking about FAT here, right? NTFS does support sparse files if
the sparse bit has been explicitly been set on it. Bit even if the sparse bit
is not set filling a file with zeros by writing after a seek long beyond the
end of the file is very fast because NTFS supports that feature what Unix
filesystems like xfs call extents.
If writing beyond the end of a file is really slow via cifs vfs in the test
case against a ntfs volume then I wonder if that operation is being really done
optimally over the wire. ntfs really isn't that bad with handling this kind of
files.
Cheers
Björn
next prev parent reply other threads:[~2013-02-28 22:54 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-25 22:28 [PATCH] CIFS: Decrease reconnection delay when switching nics Dave Chiluk
2013-02-27 11:06 ` Stefan (metze) Metzmacher
2013-02-27 16:34 ` Jeff Layton
2013-02-27 16:34 ` Jeff Layton
[not found] ` <20130227083419.0af9deaf-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
2013-02-27 22:24 ` Dave Chiluk
2013-02-27 22:24 ` Dave Chiluk
[not found] ` <512E8787.6070709-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2013-02-27 22:40 ` Steve French
2013-02-27 22:40 ` Steve French
2013-02-27 22:44 ` Dave Chiluk
2013-02-28 0:17 ` Stefan (metze) Metzmacher
2013-02-28 0:17 ` Stefan (metze) Metzmacher
2013-02-28 1:25 ` simo
2013-02-28 1:25 ` simo
[not found] ` <512E8C31.8070106-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2013-02-28 1:26 ` Tom Talpey
2013-02-28 1:26 ` Tom Talpey
2013-02-28 15:26 ` Jeff Layton
2013-02-28 15:26 ` Jeff Layton
[not found] ` <20130228072637.3b71a4f7-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
2013-02-28 16:04 ` Steve French
2013-02-28 16:04 ` Steve French
[not found] ` <CAH2r5mtBHO6woWeOJ+DJDBmF35VTfuFYo2iza--xAe7grnELAg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-28 16:47 ` Jeff Layton
2013-02-28 16:47 ` Jeff Layton
2013-02-28 17:31 ` Dave Chiluk
2013-02-28 17:31 ` Dave Chiluk
[not found] ` <512F948A.9060404-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2013-02-28 17:45 ` Steve French
2013-02-28 17:45 ` Steve French
2013-02-28 18:04 ` Jeff Layton
2013-02-28 18:04 ` Jeff Layton
2013-02-28 22:23 ` simo
2013-02-28 22:23 ` simo
2013-02-28 22:54 ` Björn JACKE [this message]
2013-02-28 22:54 ` Björn JACKE
[not found] ` <E1UBCMh-00FRaK-CC-dqLtpHMqGvUyWpdLl23E4A@public.gmane.org>
2013-03-01 0:11 ` Jeff Layton
2013-03-01 0:11 ` Jeff Layton
[not found] ` <20130228161151.0fbbff98-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
2013-03-01 2:54 ` Steve French
2013-03-01 2:54 ` Steve French
2013-02-28 0:15 ` Stefan (metze) Metzmacher
2013-02-28 0:15 ` Stefan (metze) Metzmacher
2013-02-28 13:01 ` Tom Talpey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1UBCMh-00FRaK-CC@intern.SerNet.DE \
--to=bj@sernet.de \
--cc=chiluk@canonical.com \
--cc=dave.chiluk@canonical.com \
--cc=jlayton@samba.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=metze@samba.org \
--cc=samba-technical@lists.samba.org \
--cc=sfrench@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.