[RFC] ubi: tmp hack for lstat

[RFC] ubi: tmp hack for lstat

[Sebastian Andrzej Siewior]

lstat() on /dev/ubi%d_%d returns 0 in the st_size field. This hack
allows to get the correct file size (as long as nobody updates the volume
in the meantime).

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
I have userpsace programs which stat() the file and process the
returned number bytes. The other work around is to copy the file
somewhere and use this file instead of /dev/ubi.
Artem, do you thing it is possible to implement this functionality
properly or would it be reasonable not to use stat() at all on ubi
volumes?

 drivers/mtd/ubi/cdev.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/ubi/cdev.c b/drivers/mtd/ubi/cdev.c
index 03c759b..921dd81 100644
--- a/drivers/mtd/ubi/cdev.c
+++ b/drivers/mtd/ubi/cdev.c
@@ -123,6 +123,7 @@ static int vol_cdev_open(struct inode *inode, struct file *file)
 	if (IS_ERR(desc))
 		return PTR_ERR(desc);
 
+	i_size_write(inode, desc->vol->used_bytes);
 	file->private_data = desc;
 	return 0;
 }
-- 
1.5.6.5

Re: [RFC] ubi: tmp hack for lstat

[Artem Bityutskiy]

On Sun, 2008-10-19 at 15:21 +0200, Sebastian Andrzej Siewior wrote:
> lstat() on /dev/ubi%d_%d returns 0 in the st_size field. This hack
> allows to get the correct file size (as long as nobody updates the volume
> in the meantime).
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> I have userpsace programs which stat() the file and process the
> returned number bytes. The other work around is to copy the file
> somewhere and use this file instead of /dev/ubi.
> Artem, do you thing it is possible to implement this functionality
> properly or would it be reasonable not to use stat() at all on ubi
> volumes?

Hi,

I've tried to stat various files in my /dev/ and all of them have size
0. Why UBI should be different? Indeed, stat should return size of the
inode, that is normal semantics. You suggest making stat on UBI volume
character devices return volume size. It might help your application,
but it'll confuse other applications - for example 'du', which uses stat
to calculate directory size. So am not sure it is good idea.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: [RFC] ubi: tmp hack for lstat

[Sebastian Andrzej Siewior]

* Artem Bityutskiy | 2008-10-20 08:13:57 [+0300]:

>Hi,
Hi,

>I've tried to stat various files in my /dev/ and all of them have size
>0. 
None of them is a file filestem so no one of them returns something.

>Why UBI should be different? 
As I made the patch I though that this is the expectingt behavior.
sda/hda return 0 but those are larger then a few MiBs so you use a fs on
top. So either nobody care(s|d) or it works as expected.

>Indeed, stat should return size of the
>inode, that is normal semantics. You suggest making stat on UBI volume
>character devices return volume size. It might help your application,
>but it'll confuse other applications - for example 'du', which uses stat
>to calculate directory size. So am not sure it is good idea.
It would report the size you would get after a read(). A cp()1 on ubi
would copy the content of the node unless called with -a.

I'm actually not sure what the expected behavior is. stat() returns
information about a file and ubi isn't a regular file it is a character
node. So it would be probably better to leave everything as it and
change userspace instead.

>Best regards,
>Artem Bityutskiy (???????????????? ??????????)

Sebastian

Re: [RFC] ubi: tmp hack for lstat

[Artem Bityutskiy]

On Mon, 2008-10-20 at 11:11 +0200, Sebastian Andrzej Siewior wrote:
> I'm actually not sure what the expected behavior is. stat() returns
> information about a file and ubi isn't a regular file it is a character
> node. So it would be probably better to leave everything as it and
> change userspace instead.

In my understanding, stat() should return how many bytes of data inode
contains. Stat on a character device should return amount of bytes the
character device inode contain. In ext3 major/minor are stored as
meta-data, so it returns 0.

Yes, I also think it is better if you amend your user-space application.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: [RFC] ubi: tmp hack for lstat

[Peter Korsgaard]

>>>>> "Artem" == Artem Bityutskiy <dedekind@infradead.org> writes:

Hi,

 Artem> On Mon, 2008-10-20 at 11:11 +0200, Sebastian Andrzej Siewior wrote:
 >> I'm actually not sure what the expected behavior is. stat() returns
 >> information about a file and ubi isn't a regular file it is a character
 >> node. So it would be probably better to leave everything as it and
 >> change userspace instead.

 Artem> In my understanding, stat() should return how many bytes of
 Artem> data inode contains. Stat on a character device should return
 Artem> amount of bytes the character device inode contain. In ext3
 Artem> major/minor are stored as meta-data, so it returns 0.

Exactly. The normal way to know the size of these things is to open
them and do the lseek(fd, 0, SEEK_END) thing.

-- 
Bye, Peter Korsgaard