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
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 equiv
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 aro
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 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,
On Tue, Feb 14, 2012 at 10:50 PM, Scott Long 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
> filesystem in the
On Feb 14, 2012, at 1:02 PM, Peter Jeremy wrote:
> On 2012-Feb-13 08:28:21 -0500, Gary Palmer 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.
>
>
On Wed, Feb 15, 2012 at 07:02:58AM +1100, Peter Jeremy wrote:
> On 2012-Feb-13 08:28:21 -0500, Gary Palmer 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.
>
> A
On 2012-Feb-13 08:28:21 -0500, Gary Palmer 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 and
>the disk w
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 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
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 07:36:25AM +0100, Alex Samorukov wrote:
> On 02/13/2012 06:27 AM, Adrian Chadd wrote:
> >On 12 February 2012 09:34, Alex Samorukov 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
On 02/13/2012 06:27 AM, Adrian Chadd wrote:
On 12 February 2012 09:34, Alex Samorukov 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 appropri
On 12 February 2012 09:34, Alex Samorukov 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 lay
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 cleaner
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 involved)
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 some
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 rememb
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:
1) FreeBSD kernel do not allow to have nonalignment access to device
with standard read/write commands. mmap to the entire disk (/dev/da0s1)
doesn`t work also
19 matches
Mail list logo
