> I'm not sure I understand, wouldn't the filesystem need to be involved
> at some level? How can the block layer differentiate lazilly discarded data
> blocks from ones that are still in use without the aid of the
> filesystem?
It might be me that doesn't understand.
Yes, the filesystem is invol
> FITRIM is a mounted filesystem feature to discard (or "trim") blocks which
> are not in use by the filesystem. This is useful for solid-state drives
> (SSDs) and thinly-provisioned storage. Provide access to the feature
> from the host so that filesystems can be trimmed periodically or before
>
> SEEK_HOLE could provide a very simple heuristic to detect preallocated
> files (unfortunately ext4 does not implement SEEK_HOLE yet).
SEEK_HOLE is a weird (confusing and no intuitive) API (IMO). There is
FIEMAP or whatever it's called which seems somewhat saner.
XFS specific there is also GETB
> This will enable discard on more filesystems, including ext4.
i think this should default to off
for preallocated files this will punch holes all over the place and
reallocation will cause fragmentation (guests will free and reallocat
blocks normally)
xfs has a mechanism to convert to unwritt
On Mon, Feb 25, 2008 at 08:50:40PM +, Jamie Lokier wrote:
> On Linux (and other host OSes), fdatsync() and fsync() don't always
> commit data to hard storage; it sometimes only commits it to the hard
> drive cache.
That's a filesystem bug IMO. People should be able to use f[data]sync
with so
