Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2

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

 



On Thu, Jul 03, 2008 at 10:37:36AM -0400, jim owens wrote:
> As Jamie pointed out, this:
> I disagree with these:
>
>> * FIEMAP_EXTENT_SECONDARY
>> The data for this extent is in secondary storage (e.g. HSM).  If the
>> data is not also in the filesystem, then FIEMAP_EXTENT_NO_DIRECT
>> should also be set.
....
> Or, as was said before, maybe HSM should wait until we
> know what it really needs.

Given that other flags for HSM interfacing have already been removed
(i.e. the 'don't recall HSM resident extents to map them' flag) this
serveѕ little purpose.

As to what HSM needs, we know exactly what it needs - that's one of
the things XFS has been working intimately with for years and years.
Those needs fed into the original fiemap interface design and this
flag was one of them (as was the 'don't read' flag that has already
been removed).

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx
--
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