Re: [PATCH 0/7] Discard requests, v2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2008-08-12 at 19:10 +0100, Jamie Lokier wrote:
> Wouldn't an explicit barrier be (a) slow if it's a hard-barrier, and
> (b) as a soft-barrier, overly constrain scheduling, because the only
> ordering required is against a subsequent overlapping write?

Yes, a soft barrier is more than we need -- but unless we do a lot of
work in the schedulers to ensure that writes can't cross discards,
that's the best option we have.

> Explicit soft or hard barrier *before* DISCARD does need to be an
> option.  Think of journalling: Step 1 = commit "deleted file" to
> journal, 2 = hard barrier, 3 = DISCARD file data.  Barrier after does
> not seem to be required.

The barrier afterwards is to protect against immediate reallocation of
these blocks to a new inode, and the associated data write getting
scheduled _before_ the discard.

-- 
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux