Hi,
> > While trying to get affs working again, I noticed that the current
> > cont_prepare_write is hardly working, if you write to a file in steps of
> > 1024, the bytes pointer is never updated resulting in an endless loop.
>
> Testcase, please? It certainly seems to be working on FAT and HPFS -
> both are using the same thing.
Ok, now I see it, they are updating it themselves, why isn't that done
by the vfs?
> > Below is a fixed version, that also removes the bogus tricks to the
> > bytes ptr. I also "fixed" the comment, any reason we have to be
> > insulting like this?
>
> Sheer frustration from the braindead design? _Nothing_ can insult persons
> responsible for AFFS and FAT "designs". Sorry.
$ grep cont_prepare_write fs/*/*.c
fs/adfs/inode.c: prepare_write: cont_prepare_write,
fs/affs/file.c: prepare_write: cont_prepare_write,
fs/hfs/inode.c: prepare_write: cont_prepare_write,
fs/hpfs/file.c: prepare_write: cont_prepare_write,
fs/ntfs/fs.c: prepare_write: cont_prepare_write,
fs/qnx4/inode.c: prepare_write: cont_prepare_write,
Only because a fs wasn't designed for UNIX, means it's shit. Sorry, for
me it's a simple matter of respect. A fs isn't "moronic", only because
it doesn't support holes, the real design issues are somewhere else.
Anyway, probably as I only see mmu_private updates in fat and hpfs, it
looks like adfs, hfs, ntfs and qnx4 are broken as well. BTW wouldn't it
be better to introduce a i_realsize field for that, it can be useful for
other fs later as well. E.g. it can be used to fix read/truncate race
without a BKL (i_realsize only grows while file is open and truncate can
be delayed until file is closed).
> Yes. In particular, adding the whole PAGE_CACHE_SIZE to *bytes is
> _definitely_ wrong. The whole "round up to the block boundary" thing is
> there for purpose - in native environment all of these filesystems do not
> care to clean the tail of the last allocated block. So we have to do it
> for them. And we don't want to repeat such cleaning on _every_ write() -
> the first one should normalize the situation.
Rounding it up to the block size isn't a problem, the question is why do
we give the bytes ptr to cont_prepare_write, if get_block has to update
it in first place. That's probably the point that confused me here.
> If you have problems with affs_get_block() - feel free to ask, I probably
> can help. What _is_ the problem? Notice that you can assume that
> affs_get_block() will only have to create blocks immediately past the
> end-of-file.
Yes, the whole get_block/getblock stuff in affs needs a real cleanup
because of this.
bye, Roman
