Re: reiser4progs do not handle the reiser4 format changes
On Sunday 24 July 2005 03:44, Edward Shishkin wrote: Edward Shishkin wrote: David Masover wrote: Ok, please explain what this actually means for users. How will an FS made by the current reiser4progs be different than that made by the new (patched) ones that will be coming out? Is the new way better? If so, how can one take an existing FS and convert/update/tweak it to the new way? This is a common scenario: Each disk reiser4 is supposed to be supported by all kernel/reiser4. I was wrong here: the only last version of kernel/reiser4 is able to support _all_ disk file systems. Old kernels will refuse to mount file systems of new versions with the warning about wrong plugin set of root inode. Edward. Both kernel and reiser4progs have a plugin table which should be upgraded in sync. For each point A of upgrading the plugin table all reiser4progs of versions A become invalid for disk reiser4 being once mounted in the kernel/reiser4 of version = A. Is it okay? Perhaps introducing a special sub-versions of reiser4/reiser4progs for upgrading the plugin table will improve the situation.. the reiser4progs obtained from ftp.namesys.com/pub/reiser4progs/reiser4progs-1.0.4-1.tar.gz contain the fix to handle the extended plugin table correctly. -- Thanks, Vitaly Fertman
Re: reiser4progs do not handle the reiser4 format changes
Edward Shishkin wrote: David Masover wrote: Ok, please explain what this actually means for users. How will an FS made by the current reiser4progs be different than that made by the new (patched) ones that will be coming out? Is the new way better? If so, how can one take an existing FS and convert/update/tweak it to the new way? This is a common scenario: Each disk reiser4 is supposed to be supported by all kernel/reiser4. I was wrong here: the only last version of kernel/reiser4 is able to support _all_ disk file systems. Old kernels will refuse to mount file systems of new versions with the warning about wrong plugin set of root inode. Edward. Both kernel and reiser4progs have a plugin table which should be upgraded in sync. For each point A of upgrading the plugin table all reiser4progs of versions A become invalid for disk reiser4 being once mounted in the kernel/reiser4 of version = A. Is it okay? Perhaps introducing a special sub-versions of reiser4/reiser4progs for upgrading the plugin table will improve the situation.. Edward.
Re: reiser4progs do not handle the reiser4 format changes
David Masover wrote: Edward Shishkin wrote: Hans Reiser wrote: Edward Shishkin wrote: David Masover wrote: E.Gryaznova wrote: Notification: The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new reiser4 kernel code is able to handle the old format. Good, so I don't have to reformat _immediately_... But, why isn't it for 2.6.12 yet? We're already on at least 2.6.12.2, last I checked... The reiser4progs-1.0.4 are not able to handle the format changes. The fix for reiser4progs will be ready next week. Will there be a conversion tool? No. Reiser4progs just will support a set of new plugins which have been added to the kernel. In particular, mkfs.reiser4 should allow user to specify the plugins like other existing ones. This will be a way to create cryptcompress files per superblock. There is another more flexible way (which is compatible with the previous one) to create it per file/directory, but it uses deprecated metas interface.. Note: since cryptcompress plugin is unstable, the new options are supposed to be undocumented. Thanks, Edward. So why does this create a format change that breaks things? I cannot see why it should do so, please explain. I have lost a track who first called upgrading plugin_set by the terrible words disk format change. Plugin set is not a disk format, it is supposed to be upgraded.. Ok, please explain what this actually means for users. How will an FS made by the current reiser4progs be different than that made by the new (patched) ones that will be coming out? Is the new way better? If so, how can one take an existing FS and convert/update/tweak it to the new way? This is a common scenario: Each disk reiser4 is supposed to be supported by all kernel/reiser4. Both kernel and reiser4progs have a plugin table which should be upgraded in sync. For each point A of upgrading the plugin table all reiser4progs of versions A become invalid for disk reiser4 being once mounted in the kernel/reiser4 of version = A. Is it okay? Perhaps introducing a special sub-versions of reiser4/reiser4progs for upgrading the plugin table will improve the situation.. Edward.
Re: reiser4progs do not handle the reiser4 format changes
Edward Shishkin wrote: David Masover wrote: E.Gryaznova wrote: Notification: The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new reiser4 kernel code is able to handle the old format. Good, so I don't have to reformat _immediately_... But, why isn't it for 2.6.12 yet? We're already on at least 2.6.12.2, last I checked... The reiser4progs-1.0.4 are not able to handle the format changes. The fix for reiser4progs will be ready next week. Will there be a conversion tool? No. Reiser4progs just will support a set of new plugins which have been added to the kernel. In particular, mkfs.reiser4 should allow user to specify the plugins like other existing ones. This will be a way to create cryptcompress files per superblock. There is another more flexible way (which is compatible with the previous one) to create it per file/directory, but it uses deprecated metas interface.. Note: since cryptcompress plugin is unstable, the new options are supposed to be undocumented. Thanks, Edward. So why does this create a format change that breaks things? I cannot see why it should do so, please explain. We cannot change disk formats. We promised that we would not. Why did this happen? Did it have a good technical motivation or was it an accident of coding. This should not be done to users. Hans
Re: reiser4progs do not handle the reiser4 format changes
On 7/20/05, Edward Shishkin [EMAIL PROTECTED] wrote: like other existing ones. This will be a way to create cryptcompress files per superblock. There is another more flexible way (which is compatible with the previous one) to create it per file/directory, but it uses deprecated metas interface.. Per ... superblock? Excuse me? Nonselective use of this feature will be nearly useless. There must be an API to selectively control the feature. This sounds like a silly tantrum about the interface changes.
Re: reiser4progs do not handle the reiser4 format changes
Gregory Maxwell wrote: Nonselective use of this feature will be nearly useless. No, that is not true. Most users are not interested in specifying per file whether we can compress it. So our plugin tries to compress the first 64k, and if it fails to it assumes the file is not compressable. This is not always the correct thing, so being able to specify would be nice, but it solves 80% of the problem, and that means we can deal with the other 20% next year. Hans
Re: reiser4progs do not handle the reiser4 format changes
Hans Reiser wrote: Edward Shishkin wrote: David Masover wrote: E.Gryaznova wrote: Notification: The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new reiser4 kernel code is able to handle the old format. Good, so I don't have to reformat _immediately_... But, why isn't it for 2.6.12 yet? We're already on at least 2.6.12.2, last I checked... The reiser4progs-1.0.4 are not able to handle the format changes. The fix for reiser4progs will be ready next week. Will there be a conversion tool? No. Reiser4progs just will support a set of new plugins which have been added to the kernel. In particular, mkfs.reiser4 should allow user to specify the plugins like other existing ones. This will be a way to create cryptcompress files per superblock. There is another more flexible way (which is compatible with the previous one) to create it per file/directory, but it uses deprecated metas interface.. Note: since cryptcompress plugin is unstable, the new options are supposed to be undocumented. Thanks, Edward. So why does this create a format change that breaks things? I cannot see why it should do so, please explain. I have lost a track who first called upgrading plugin_set by the terrible words disk format change. Plugin set is not a disk format, it is supposed to be upgraded.. We cannot change disk formats. We promised that we would not. Why did this happen? Did it have a good technical motivation or was it an accident of coding. This should not be done to users. Hans
Re: reiser4progs do not handle the reiser4 format changes
Edward Shishkin wrote: Hans Reiser wrote: Edward Shishkin wrote: David Masover wrote: E.Gryaznova wrote: Notification: The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new reiser4 kernel code is able to handle the old format. Good, so I don't have to reformat _immediately_... But, why isn't it for 2.6.12 yet? We're already on at least 2.6.12.2, last I checked... The reiser4progs-1.0.4 are not able to handle the format changes. The fix for reiser4progs will be ready next week. Will there be a conversion tool? No. Reiser4progs just will support a set of new plugins which have been added to the kernel. In particular, mkfs.reiser4 should allow user to specify the plugins like other existing ones. This will be a way to create cryptcompress files per superblock. There is another more flexible way (which is compatible with the previous one) to create it per file/directory, but it uses deprecated metas interface.. Note: since cryptcompress plugin is unstable, the new options are supposed to be undocumented. Thanks, Edward. So why does this create a format change that breaks things? I cannot see why it should do so, please explain. I have lost a track who first called upgrading plugin_set by the terrible words disk format change. Plugin set is not a disk format, it is supposed to be upgraded.. Ok, please explain what this actually means for users. How will an FS made by the current reiser4progs be different than that made by the new (patched) ones that will be coming out? Is the new way better? If so, how can one take an existing FS and convert/update/tweak it to the new way? -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.2/55 - Release Date: 7/21/2005
reiser4progs do not handle the reiser4 format changes
Notification: The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new reiser4 kernel code is able to handle the old format. The reiser4progs-1.0.4 are not able to handle the format changes. The fix for reiser4progs will be ready next week. Thanks, Lena
Re: reiser4progs do not handle the reiser4 format changes
E.Gryaznova wrote: Notification: The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new reiser4 kernel code is able to handle the old format. Good, so I don't have to reformat _immediately_... But, why isn't it for 2.6.12 yet? We're already on at least 2.6.12.2, last I checked... The reiser4progs-1.0.4 are not able to handle the format changes. The fix for reiser4progs will be ready next week. Will there be a conversion tool?
Re: reiser4progs do not handle the reiser4 format changes
David Masover wrote: E.Gryaznova wrote: Notification: The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new reiser4 kernel code is able to handle the old format. Good, so I don't have to reformat _immediately_... But, why isn't it for 2.6.12 yet? We're already on at least 2.6.12.2, last I checked... The reiser4progs-1.0.4 are not able to handle the format changes. The fix for reiser4progs will be ready next week. Will there be a conversion tool? No. Reiser4progs just will support a set of new plugins which have been added to the kernel. In particular, mkfs.reiser4 should allow user to specify the plugins like other existing ones. This will be a way to create cryptcompress files per superblock. There is another more flexible way (which is compatible with the previous one) to create it per file/directory, but it uses deprecated metas interface.. Note: since cryptcompress plugin is unstable, the new options are supposed to be undocumented. Thanks, Edward.
Re: reiser4progs do not handle the reiser4 format changes
E.Gryaznova wrote: Notification: The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new reiser4 kernel code is able to handle the old format. The reiser4progs-1.0.4 are not able to handle the format changes. The fix for reiser4progs will be ready next week. Thanks, Lena I would like to apologize to the users for this, it should not have been done this way.
