Searched hist:"101 ee137d32adc5b53f5c2a61fbda8f70f994845" (Results 1 – 9 of 9) sorted by relevance
| /openbmc/linux/fs/udf/ |
| H A D | misc.c | diff 101ee137d32adc5b53f5c2a61fbda8f70f994845 Wed Jan 18 06:27:07 CST 2023 Jan Kara <jack@suse.cz> udf: Drop VARCONV support
UDF was supporting a strange mode where the media was containing 7
blocks of unknown data for every 32 blocks of the filesystem. I have yet
to see the media that would need such conversion (maybe it comes from
packet writing times) and the conversions have been inconsistent in the
code. In particular any write will write to a wrong block and corrupt
the media. This is an indication and no user actually needs this so
let's just drop the support instead of trying to fix it.
Signed-off-by: Jan Kara <jack@suse.cz>
|
| H A D | truncate.c | diff 101ee137d32adc5b53f5c2a61fbda8f70f994845 Wed Jan 18 06:27:07 CST 2023 Jan Kara <jack@suse.cz> udf: Drop VARCONV support
UDF was supporting a strange mode where the media was containing 7
blocks of unknown data for every 32 blocks of the filesystem. I have yet
to see the media that would need such conversion (maybe it comes from
packet writing times) and the conversions have been inconsistent in the
code. In particular any write will write to a wrong block and corrupt
the media. This is an indication and no user actually needs this so
let's just drop the support instead of trying to fix it.
Signed-off-by: Jan Kara <jack@suse.cz>
|
| H A D | directory.c | diff 101ee137d32adc5b53f5c2a61fbda8f70f994845 Wed Jan 18 06:27:07 CST 2023 Jan Kara <jack@suse.cz> udf: Drop VARCONV support
UDF was supporting a strange mode where the media was containing 7
blocks of unknown data for every 32 blocks of the filesystem. I have yet
to see the media that would need such conversion (maybe it comes from
packet writing times) and the conversions have been inconsistent in the
code. In particular any write will write to a wrong block and corrupt
the media. This is an indication and no user actually needs this so
let's just drop the support instead of trying to fix it.
Signed-off-by: Jan Kara <jack@suse.cz>
|
| H A D | balloc.c | diff 101ee137d32adc5b53f5c2a61fbda8f70f994845 Wed Jan 18 06:27:07 CST 2023 Jan Kara <jack@suse.cz> udf: Drop VARCONV support
UDF was supporting a strange mode where the media was containing 7
blocks of unknown data for every 32 blocks of the filesystem. I have yet
to see the media that would need such conversion (maybe it comes from
packet writing times) and the conversions have been inconsistent in the
code. In particular any write will write to a wrong block and corrupt
the media. This is an indication and no user actually needs this so
let's just drop the support instead of trying to fix it.
Signed-off-by: Jan Kara <jack@suse.cz>
|
| H A D | udf_sb.h | diff 101ee137d32adc5b53f5c2a61fbda8f70f994845 Wed Jan 18 06:27:07 CST 2023 Jan Kara <jack@suse.cz> udf: Drop VARCONV support
UDF was supporting a strange mode where the media was containing 7
blocks of unknown data for every 32 blocks of the filesystem. I have yet
to see the media that would need such conversion (maybe it comes from
packet writing times) and the conversions have been inconsistent in the
code. In particular any write will write to a wrong block and corrupt
the media. This is an indication and no user actually needs this so
let's just drop the support instead of trying to fix it.
Signed-off-by: Jan Kara <jack@suse.cz>
|
| H A D | udfdecl.h | diff 101ee137d32adc5b53f5c2a61fbda8f70f994845 Wed Jan 18 06:27:07 CST 2023 Jan Kara <jack@suse.cz> udf: Drop VARCONV support
UDF was supporting a strange mode where the media was containing 7
blocks of unknown data for every 32 blocks of the filesystem. I have yet
to see the media that would need such conversion (maybe it comes from
packet writing times) and the conversions have been inconsistent in the
code. In particular any write will write to a wrong block and corrupt
the media. This is an indication and no user actually needs this so
let's just drop the support instead of trying to fix it.
Signed-off-by: Jan Kara <jack@suse.cz>
|
| H A D | namei.c | diff 101ee137d32adc5b53f5c2a61fbda8f70f994845 Wed Jan 18 06:27:07 CST 2023 Jan Kara <jack@suse.cz> udf: Drop VARCONV support
UDF was supporting a strange mode where the media was containing 7
blocks of unknown data for every 32 blocks of the filesystem. I have yet
to see the media that would need such conversion (maybe it comes from
packet writing times) and the conversions have been inconsistent in the
code. In particular any write will write to a wrong block and corrupt
the media. This is an indication and no user actually needs this so
let's just drop the support instead of trying to fix it.
Signed-off-by: Jan Kara <jack@suse.cz>
|
| H A D | inode.c | diff 101ee137d32adc5b53f5c2a61fbda8f70f994845 Wed Jan 18 06:27:07 CST 2023 Jan Kara <jack@suse.cz> udf: Drop VARCONV support
UDF was supporting a strange mode where the media was containing 7
blocks of unknown data for every 32 blocks of the filesystem. I have yet
to see the media that would need such conversion (maybe it comes from
packet writing times) and the conversions have been inconsistent in the
code. In particular any write will write to a wrong block and corrupt
the media. This is an indication and no user actually needs this so
let's just drop the support instead of trying to fix it.
Signed-off-by: Jan Kara <jack@suse.cz>
|
| H A D | super.c | diff 101ee137d32adc5b53f5c2a61fbda8f70f994845 Wed Jan 18 06:27:07 CST 2023 Jan Kara <jack@suse.cz> udf: Drop VARCONV support
UDF was supporting a strange mode where the media was containing 7
blocks of unknown data for every 32 blocks of the filesystem. I have yet
to see the media that would need such conversion (maybe it comes from
packet writing times) and the conversions have been inconsistent in the
code. In particular any write will write to a wrong block and corrupt
the media. This is an indication and no user actually needs this so
let's just drop the support instead of trying to fix it.
Signed-off-by: Jan Kara <jack@suse.cz>
|