On 02/15/2012 05:50 AM, Scott Long wrote:
What would be nice is a generic caching subsystem that any FS can use
- similar to the old block devices but with hooks to allow the FS to
request read-ahead, advise of unwanted blocks and ability to flush
dirty blocks in a requested order with the
On Feb 20, 2012, at 12:24 PM, Alex Samorukov wrote:
On 02/15/2012 05:50 AM, Scott Long wrote:
What would be nice is a generic caching subsystem that any FS can use
- similar to the old block devices but with hooks to allow the FS to
request read-ahead, advise of unwanted blocks and ability
On Wed, Feb 15, 2012 at 12:27:19AM -0600, Adam Vande More wrote:
On Tue, Feb 14, 2012 at 10:50 PM, Scott Long sco...@samsco.org wrote:
Any filesystem that uses bread/bwrite/cluster_read are already using the
generic caching subsystem that you propose. This includes UDF, CD9660,
MSDOS,
on 15/02/2012 06:50 Scott Long said the following:
The ARC is limited by available wired memory; attempts to allocate such
memory will evict pages from the buffer cache as necessary, until all
available RAM is consumed. If anything, ZFS starves the rest of the system,
not the other way
On 2012-Feb-13 08:28:21 -0500, Gary Palmer gpal...@freebsd.org wrote:
The filesystem is the *BEST* place to do caching. It knows what metadata
is most effective to cache and what other data (e.g. file contents) doesn't
need to be cached.
Agreed.
Any attempt to do this in layers between the FS
On Wed, Feb 15, 2012 at 07:02:58AM +1100, Peter Jeremy wrote:
On 2012-Feb-13 08:28:21 -0500, Gary Palmer gpal...@freebsd.org wrote:
The filesystem is the *BEST* place to do caching. It knows what metadata
is most effective to cache and what other data (e.g. file contents) doesn't
need to be
On Feb 14, 2012, at 1:02 PM, Peter Jeremy wrote:
On 2012-Feb-13 08:28:21 -0500, Gary Palmer gpal...@freebsd.org wrote:
The filesystem is the *BEST* place to do caching. It knows what metadata
is most effective to cache and what other data (e.g. file contents) doesn't
need to be cached.
On Tue, Feb 14, 2012 at 10:50 PM, Scott Long sco...@samsco.org wrote:
Any filesystem that uses bread/bwrite/cluster_read are already using the
generic caching subsystem that you propose. This includes UDF, CD9660,
MSDOS, NTFS, XFS, ReiserFS, EXT2FS, and HPFS, i.e. every local storage
On Mon, Feb 13, 2012 at 07:36:25AM +0100, Alex Samorukov wrote:
On 02/13/2012 06:27 AM, Adrian Chadd wrote:
On 12 February 2012 09:34, Alex Samorukovm...@os2.kiev.ua wrote:
Yes. But it will nit fix non-cached access to the disk (raw) devices. And
this is the main reason why ntfs-3g and
On 02/13/2012 02:28 PM, Gary Palmer wrote:
Yes. But it will nit fix non-cached access to the disk (raw) devices. And
this is the main reason why ntfs-3g and exfat are much slower then working
on Linux.
But _that_ can be fixed with the appropriate application of a sensible
caching layer.
With
On Mon, Feb 13, 2012 at 03:50:36PM +0100, Alex Samorukov wrote:
On 02/13/2012 02:28 PM, Gary Palmer wrote:
Yes. But it will nit fix non-cached access to the disk (raw) devices.
And
this is the main reason why ntfs-3g and exfat are much slower then
working
on Linux.
But _that_ can be
I tend to say the right solution to a problem is to not do it wrong.
But.. given that Linux is fine with all the unaligned accesses, is the
major sticking point here the fact that Linux's block dev layer is
doing all the caching that FreeBSD's direct device layer isn't, and
all of those (cached)
On 02/12/2012 01:54 AM, Adrian Chadd wrote:
Hi,
What about the disk access is unaligned? Do you mean not sector aligned? or?
Hi. Sector aligned.
This is a common problem people face doing disk IO analysis.
The whole point about not allowing unaligned access is to make the
disk IO path
On 12 February 2012 09:34, Alex Samorukov m...@os2.kiev.ua wrote:
Yes. But it will nit fix non-cached access to the disk (raw) devices. And
this is the main reason why ntfs-3g and exfat are much slower then working
on Linux.
But _that_ can be fixed with the appropriate application of a
On 02/13/2012 06:27 AM, Adrian Chadd wrote:
On 12 February 2012 09:34, Alex Samorukovm...@os2.kiev.ua wrote:
Yes. But it will nit fix non-cached access to the disk (raw) devices. And
this is the main reason why ntfs-3g and exfat are much slower then working
on Linux.
But _that_ can be fixed
Hi,
What about the disk access is unaligned? Do you mean not sector aligned? or?
This is a common problem people face doing disk IO analysis.
The whole point about not allowing unaligned access is to make the
disk IO path cleaner. It does mean that the filesystem code (and GEOM
modules
schrieb Alex Samorukov am 26.01.2012 14:52 (localtime):
Hi,
I ported exfat fuse module to FreeBSD (PR 164473) and found that it
works much slower then on Linux. I found 2 reasons for this:
Thanks a lot! I saw the new port :-)
Hope that someone can help you improove fusefs-kmod. I remember
On 01/31/2012 11:19 AM, Harald Schmalzbauer wrote:
schrieb Alex Samorukov am 26.01.2012 14:52 (localtime):
Hi,
I ported exfat fuse module to FreeBSD (PR 164473) and found that it
works much slower then on Linux. I found 2 reasons for this:
Thanks a lot! I saw the new port :-)
Hope that
18 matches
Mail list logo
