> > > Finally, if vmtruncate succeeds, and ATTR_SIZE is the only change
> > > requested, we now fall-through and mark_inode_dirty. If a filesystem
> > > did not have a ->truncate function, then vmtruncate will have changed
> > > i_size, without marking the inode as 'dirty', and I think this is wrong.
> >
> > And if filesystem does not have a ->truncate() function and it caller
> > was [f]truncate(), ctime and mtime won't be set.
> >
> > That's wrong too, isn't it?
>
> I don't think that is a problem.
> The filesystem would have had a ->setattr function which would have
> been told that the size had changed, and it would have had to change
> the inode, and so would have updated the ctime and probably mtime.
What if filesystem has neither ->truncate() nor ->setattr()?
E.g. ramfs and derivatives.
> Changing i_size without marking the inode dirty is an issue of
> consistency of common data structures and inode_setattr should be
> careful about that.
>
> Changing ctime/mtime when the isize changes is an issue of filesystem
> correctness, and the filesystem callbacks should handle that.
Yes, but VFS should have a sane default when filesystem doesn't have
the methods. It's the same with all the other methods.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
