Re: [reiserfs-list] ReiserFS 3.5.32 stability ?
On Mon, May 28, 2001 at 06:41:42AM +0400, Vladimir V. Saveliev wrote: * there is no easy way to tell if a particular stat-data is in v1 or v2 format in link. Yes, there is. They have different length. But this information is not easily available where it's actually used, in mkdir and link. (you're talking about on-disk structure length, right?) * save stat-data version number in reiserfs-specific part of the inode. (e.g. in i_version - we discussed this once before, but for some reason it was not changed) Looking at it again, I see that i_version _is_ set, only it's always set to 1 for directories. Maybe instead of i_version the inode should have a pointer to a version-dependent struct, that can include e.g. MAX_LINKS and others? I suppose if other stat-data versions are invented later on, there will be many things that differ (e.g. a stat-data version without timestamps may make sense?) filesystem specific union of struct inode is still almost not used by reiserfs, so, we can store there a lot of things like real number of links, etc real number of links should be stored in the generic part of the inode, so stat and friends will find it. But what I suggested was a datastructure that didn't only depend on filesystem, but on inode items version for this particular inode - it can hold constants and potentially pointers to functions that differ from item-version to item-version. -- Ragnar Kjørstad Big Storage
Re: [reiserfs-list] ReiserFS 3.5.32 stability ?
On Mon, May 28, 2001 at 07:07:27AM +0200, Henrik Nordstrom wrote: and in case of stat, link counts above a couple of hundreds is rarely important, so for most practical uses returning 65535 for counts above 65535 is perfectly fine. Do you think returning 65535 is better than returning 1 for directories? Last time this issue came up, the conclution was that some applications (find) could potentially use nlink to optimize search for subdirectories, but this optimization would be turned off if they found nlink to be 1. libc also will have to change, and that will probably make problems for existing programs. libc is already using int for both stat and stat64. Was this changed resently? I'm pretty sure last time I looked at this I found that libc would have to be changed.. maybe I just don't remember it correctly. So for regular stat, 32 bits are used in app-libc, but only 16 bit in libc-kernel? So if we change libc-kernel interface, we can make 32 bit nlink work even for applications that use regular stat? I suppose that's a long and painful thing to do, and not worth it since stat64 is there anyway? -- Ragnar Kjørstad Big Storage
Re: [reiserfs-list] ReiserFS 3.5.32 stability ?
Hi
Ragnar Kjørstad wrote:
On Mon, May 28, 2001 at 06:41:42AM +0400, Vladimir V. Saveliev wrote:
* there is no easy way to tell if a particular stat-data is in v1 or v2
format in link.
Yes, there is. They have different length.
But this information is not easily available where it's actually used,
in mkdir and link. (you're talking about on-disk structure length,
right?)
Yes.
But we can add something like i_sd_version in addition to i_version.
* save stat-data version number in reiserfs-specific part of the inode.
(e.g. in i_version - we discussed this once before, but for some
reason it was not changed)
Looking at it again, I see that i_version _is_ set, only it's always set
to 1 for directories.
This i_vesion should be renamed to i_key_version. Because it says which keys do all
items (but stat data) of an object have.
Directory items (even if a directory has new stat data) have keys of old format.
Maybe instead of i_version the inode should have a pointer to a
version-dependent struct, that can include e.g. MAX_LINKS and others? I
suppose if other stat-data versions are invented later on, there will be
many things that differ (e.g. a stat-data version without timestamps may
make sense?)
filesystem specific union of struct inode is still almost not used by reiserfs, so,
we can store there a lot of things like real number of links, etc
real number of links should be stored in the generic part of the inode,
so stat and friends will find it.
Yes, when inode's i_nlink will get long enough.
But what I suggested was a datastructure that didn't only depend on
filesystem, but on inode items version for this particular inode - it
can hold constants and potentially pointers to functions that differ
from item-version to item-version.
Would something like
union reisersf_inode_info {
struct stat_data_v1 v1_data;
struct stat_data_v1 v2_data;
struct stat_data_v1 v3_data;
};
work? I just think that we should avoid need to care about allocation/freeing of that
per inode dtastructure.
Thanks,
vs
Re: [reiserfs-list] ReiserFS 3.5.32 stability ?
Henrik Nordstrom wrote:
Vladimir V. Saveliev wrote:
It is doable, but afaics now it looks almost useless as far as st_nlink is 16 bit
even in stat64.
glibc uses int for link count (all modes).
typedef __u_int __nlink_t; /* Type of file link counts. */
kernel stat uses short
struct stat {
[...]
unsigned short st_nlink;
kernel stat64 also uses int
struct stat64 {
[...]
unsigned intst_nlink;
and in case of stat, link counts above a couple of hundreds is rarely
important, so for most practical uses returning 65535 for counts above
65535 is perfectly fine.
libc also will have to change, and that will probably make problems for existing
programs.
libc is already using int for both stat and stat64.
Ok, but if libc's struct stat and kernel's struct stat are that different then libc's
stat would have to do something to interpret properly what was put in its buffer by
sys_stat?
Thanks,
vs
--
Henrik Nordstrom
Re: [reiserfs-list] ReiserFS 3.5.32 stability ?
On Sun, May 27, 2001 at 06:12:22AM +0400, Vladimir V. Saveliev wrote: 2. What are the differences between ReiserFS for 2.2.x kernels and 2.4.x kernels as for now ? Except the target kernel version, of course... There are 2 formats of reiserfs. They are referred to as 3.5 and 3.6. mkreiserfs of reiserfsprogs-3.x.0j (for instance) has a switch (-v) to create either 3.5 (-v 1) or 3.6 format (-v 2 or default). Under 2.4 you can work with both 3.5 and 3.6 formats. Under 2.2 you can work only with 3.5 format filesystems. Why isn't the switch -v 3.5 and -v 3.6 ? well, suppose it's too late to change anyway... On a filesystem of 3.6 format you can have files longer than 2 gb and have more that 64k links to a file. If you're refering to my patch, it doesn't allow more than 64k links, only more than 64k subdirectories. (but the format has room for 64k links) -- Ragnar Kjørstad Big Storage
Re: [reiserfs-list] ReiserFS 3.5.32 stability ?
Hi Ragnar Kjørstad wrote: On Sun, May 27, 2001 at 06:12:22AM +0400, Vladimir V. Saveliev wrote: 2. What are the differences between ReiserFS for 2.2.x kernels and 2.4.x kernels as for now ? Except the target kernel version, of course... There are 2 formats of reiserfs. They are referred to as 3.5 and 3.6. mkreiserfs of reiserfsprogs-3.x.0j (for instance) has a switch (-v) to create either 3.5 (-v 1) or 3.6 format (-v 2 or default). Under 2.4 you can work with both 3.5 and 3.6 formats. Under 2.2 you can work only with 3.5 format filesystems. Why isn't the switch -v 3.5 and -v 3.6 ? I do not know. Maybe because this terminology has settled well after -v was added to mkreiserfs. Or maybe because 3.6 format has 2 in a field of super block called s_version. well, suppose it's too late to change anyway... reiserfsprogs is in flux anyway - so it probably should be changed. On a filesystem of 3.6 format you can have files longer than 2 gb and have more that 64k links to a file. If you're refering to my patch, it doesn't allow more than 64k links, only more than 64k subdirectories. (but the format has room for 64k links) Oh, yes, we should have allowed that (more than 64535 links) for any files. Thanks, vs -- Ragnar Kjørstad Big Storage
Re: [reiserfs-list] ReiserFS 3.5.32 stability ?
On Sun, May 27, 2001 at 11:47:51PM +0400, Vladimir V. Saveliev wrote: On a filesystem of 3.6 format you can have files longer than 2 gb and have more that 64k links to a file. If you're refering to my patch, it doesn't allow more than 64k links, only more than 64k subdirectories. (but the format has room for 64k links) Oh, yes, we should have allowed that (more than 64535 links) for any files. If I remember correctly, this is not trivial, because: * we must keep the correct link-count for regular files, or we may end up with a file without names without knowing it. (and we would leak disk space, as it would not get deleted) * we can't allow 64k links to file if that particular file has stat- data in v1 format. * there is no easy way to tell if a particular stat-data is in v1 or v2 format in link. But maybe we could: * define nlink_t to be unsigned int (it is unsigned short now) * fix inode2sd, so it uses cpu_to_le32 instead of cpu_to_le16 for i_nlink. (I suppose this is just a typo, and should be fixed anyway?) * save stat-data version number in reiserfs-specific part of the inode. (e.g. in i_version - we discussed this once before, but for some reason it was not changed) * change cp_old_stat() and cp_new_stat() to put magic number in nlink if inode-i_nlink 2^32. 1? I suppose if we do this, we can remove the stuff I wrote to allow 64k subdirectories. BUT, if we remove it, then users that actually have 64k subdirectories will get warning reiserfs_rmdir: empty directory has nlink != 2 (%d) when they remove it. We could leave the if nlink==1 test in there, but just remove the if nlink REISERFS_MAX_LINKS test. We also need to put the tests for too many links back in mkdir - and this test needs to check the version-number for the stat-data. Maybe instead of i_version the inode should have a pointer to a version-dependent struct, that can include e.g. MAX_LINKS and others? I suppose if other stat-data versions are invented later on, there will be many things that differ (e.g. a stat-data version without timestamps may make sense?) -- Ragnar Kjørstad Big Storage
Re: [reiserfs-list] ReiserFS 3.5.32 stability ?
Hi Ragnar Kjørstad wrote: On Sun, May 27, 2001 at 11:47:51PM +0400, Vladimir V. Saveliev wrote: On a filesystem of 3.6 format you can have files longer than 2 gb and have more that 64k links to a file. If you're refering to my patch, it doesn't allow more than 64k links, only more than 64k subdirectories. (but the format has room for 64k links) Oh, yes, we should have allowed that (more than 64535 links) for any files. If I remember correctly, this is not trivial, because: It is doable, but afaics now it looks almost useless as far as st_nlink is 16 bit even in stat64. * we must keep the correct link-count for regular files, or we may end up with a file without names without knowing it. (and we would leak disk space, as it would not get deleted) * we can't allow 64k links to file if that particular file has stat- data in v1 format. Yes, I meant v2 file only. * there is no easy way to tell if a particular stat-data is in v1 or v2 format in link. Yes, there is. They have different length. But maybe we could: * define nlink_t to be unsigned int (it is unsigned short now) libc also will have to change, and that will probably make problems for existing programs. * fix inode2sd, so it uses cpu_to_le32 instead of cpu_to_le16 for i_nlink. (I suppose this is just a typo, and should be fixed anyway?) Yes. * save stat-data version number in reiserfs-specific part of the inode. (e.g. in i_version - we discussed this once before, but for some reason it was not changed) * change cp_old_stat() and cp_new_stat() to put magic number in nlink if inode-i_nlink 2^32. 1? I suppose if we do this, we can remove the stuff I wrote to allow 64k subdirectories. BUT, if we remove it, then users that actually have 64k subdirectories will get warning reiserfs_rmdir: empty directory has nlink != 2 (%d) when they remove it. We could leave the if nlink==1 test in there, but just remove the if nlink REISERFS_MAX_LINKS test. We also need to put the tests for too many links back in mkdir - and this test needs to check the version-number for the stat-data. Maybe instead of i_version the inode should have a pointer to a version-dependent struct, that can include e.g. MAX_LINKS and others? I suppose if other stat-data versions are invented later on, there will be many things that differ (e.g. a stat-data version without timestamps may make sense?) filesystem specific union of struct inode is still almost not used by reiserfs, so, we can store there a lot of things like real number of links, etc Thanks, vs
Re: [reiserfs-list] ReiserFS 3.5.32 stability ?
Vladimir V. Saveliev wrote:
It is doable, but afaics now it looks almost useless as far as st_nlink is 16 bit
even in stat64.
glibc uses int for link count (all modes).
typedef __u_int __nlink_t; /* Type of file link counts. */
kernel stat uses short
struct stat {
[...]
unsigned short st_nlink;
kernel stat64 also uses int
struct stat64 {
[...]
unsigned intst_nlink;
and in case of stat, link counts above a couple of hundreds is rarely
important, so for most practical uses returning 65535 for counts above
65535 is perfectly fine.
libc also will have to change, and that will probably make problems for existing
programs.
libc is already using int for both stat and stat64.
--
Henrik Nordstrom
Re: [reiserfs-list] ReiserFS 3.5.32 stability ?
Hi Przemyslaw Wegrzyn wrote: I'd like to use ReiserFS with 2.2.19, and got 3 simple questions: 1. Are there any known issues/problems with ReiserFS 3.5.32 I should be aware of ? I would recommend few minor fixes (attached). 2. What are the differences between ReiserFS for 2.2.x kernels and 2.4.x kernels as for now ? Except the target kernel version, of course... There are 2 formats of reiserfs. They are referred to as 3.5 and 3.6. mkreiserfs of reiserfsprogs-3.x.0j (for instance) has a switch (-v) to create either 3.5 (-v 1) or 3.6 format (-v 2 or default). Under 2.4 you can work with both 3.5 and 3.6 formats. Under 2.2 you can work only with 3.5 format filesystems. On a filesystem of 3.6 format you can have files longer than 2 gb and have more that 64k links to a file. 3. It's imposible to move back from 2.4.x back to 2.2.x, without recreating Reiser filesystem on a partition, isn't ? If you use 3.5 format you are able to go back and forward between 2.2 and 2.4. If you have created 3.6 format or once mounted 3.5 filesystem under 2.4 with -o conv - you can not go back to 2.2. Thanks, vs -=Czaj-nick=-
