On Mon, 24 Jul 2000, Roman Zippel wrote:
> 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?
Because actual _allocation_ unit may have nothing to blocksize and be
invisible to VFS. Check fatfs - it uses the thing to trigger allocation,
but actual zero-out goes on per-sector basis.
> > 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,
???? Not on this box. What version are you using?
> fs/affs/file.c: prepare_write: cont_prepare_write,
> fs/hfs/inode.c: prepare_write: cont_prepare_write,
Ditto.
> fs/hpfs/file.c: prepare_write: cont_prepare_write,
Ditto.
> fs/ntfs/fs.c: prepare_write: cont_prepare_write,
Ditto.
> fs/qnx4/inode.c: prepare_write: cont_prepare_write,
Ditto.
They are _calling_ the thing, but they would simply refuse to compile if
they would have such lines - different prototypes.
BTW, when that comment went in it was FAT, HPFS and AFFS.
> 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.
And you _bet_ that they are. No, lack of holes per se is not
horrible. But there is a _lot_ of things about AFFS and FAT (and to some
extent HPFS) design that are past "horrible" - "Lovecraftian" would be
more accurate. But that's another rant...
> 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
>From adfs_get_block():
...
/* don't support allocation of blocks yet */
return -EIO;
NTFS is not just broken, it eats filesystems in rw mode.
QNX4 does not allocate blocks ("// to be done" says the driver)
HFS refuses to allocate anything. Probably broken...
> 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).
Not needed. That race is taken care of - readpage() never does access past
i_size and has the page locked, while vmtruncate() starts with setting
i_size (on shrinking truncate(), that is), then goes through all pages in
affected area and grabs the lock on all of them (one by one, not
simultaneously, indeed) and only then calls ->truncate().
So readpage() in affected area that began before we've set ->i_size will
be completed prior to call of ->truncate() and any attempt after setting
->i_size will see new ->i_size and will not bother ->truncate() at all.
_That_ one is OK. There are very scary dragons around ->truncate(), but
a) they are unrelated to that
b) knowledge of realsize won't help
c) let's take that to email.
> 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.
cont_prepare_write() has to zero the tail of the last block out ;-<
> > 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.
Well, it will get simpler - all logics with growing the chain shrinks a
lot, AFAICS...
