- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 28 2018
Jan 27 2018
Jan 25 2018
Jan 24 2018
Jan 23 2018
Jan 22 2018
This is small enough that shouldn't affect upstream merging (also the code is very FreeBSD-specific).
It also respects the general objective of the code.
Jan 21 2018
Jan 19 2018
In D13964#293442, @fsu wrote:In D13964#293380, @pfg wrote:In D13964#293266, @fsu wrote:In D13964#293256, @pfg wrote:Hmm.. it seems like we are getting to a rather complete ext4 implementation, which is positive. On the downside the code is diverging from UFS. We just can't have both I guess.
There are another features like RO_COMPAT_QUOTA, INCOMPAT_INLINE_DATA, etc, but from my current point of view, it is not so, important, if it will be required to implement it. I think it a not a problem.
The only feature, which will be difficult to implement is RO_COMPAT_BIGALLOC, but I hope it will be not widely used by linux.I haven't looked at ext4 for a while but most of those features seem to require some obscure collaboration from the kernel, that is out of the scope of the driver. There's also the issue that most of the interesting enhancements in linux assume there is journalling.
I am not sure, that journal feature is required for non-native file system, also it will be difficult to test it.
In D13964#293266, @fsu wrote:In D13964#293256, @pfg wrote:Hmm.. it seems like we are getting to a rather complete ext4 implementation, which is positive. On the downside the code is diverging from UFS. We just can't have both I guess.
There are another features like RO_COMPAT_QUOTA, INCOMPAT_INLINE_DATA, etc, but from my current point of view, it is not so, important, if it will be required to implement it. I think it a not a problem.
The only feature, which will be difficult to implement is RO_COMPAT_BIGALLOC, but I hope it will be not widely used by linux.
A sidenote: I just noticed META_BG is supported on ext3 too.
Hmm.. it seems like we are getting to a rather complete ext4 implementation, which is positive. On the downside the code is diverging from UFS. We just can't have both I guess.
In any case , let me mention that EXT4F_RO_INCOMPAT_SUPP was created as a dirty hack: to workaround for features that we were not planning to support at all but that we needed to fake in order to read the partition.
We should remove EXT4F_RO_INCOMPAT_SUPP as it has fulfilled its purpose.
Jan 17 2018
Jan 16 2018
Jan 15 2018
For the record: the changes were committed by parts in a series of commits from r328016 to r328026.
Jan 14 2018
Jan 13 2018
I committed sys/dev in rr327949 so drop those from the Revision.
Jan 12 2018
This should be a minimal and more straightforward replacement.
Jan 11 2018
Drop the arc4random change for now as to unblock this change.
In D13837#290289, @cem wrote:In D13837#290288, @pfg wrote:It is now the case that it panics right
Right.
(OpenBSD panics also, I think)?
No idea.
Can we have it return NULL for M_NOWAIT and panic for M_WAITOK?
No, I don't think that makes any sense.
When I started this changes, mallocarray(9) would return NULL on overflow, and for the M_WAITOK case the code was not prepared to handle that, so I avoided M_WAITOK changes for this revision (I was not going to do it at all).
Jan 10 2018
In D13837#290278, @cem wrote:Was this mechanical (with e.g. coccinelle)?
Nope ... I checked it on opengrok and then by hand.
In D13835#290226, @dumbbell wrote:Hi!
What is the benefit of using mallocarray() here?
In D13810#289917, @fsu wrote:In D13810#289909, @pfg wrote:In D13810#289828, @fsu wrote:In D13810#289543, @pfg wrote:A thought : would it be possible to checksum only what we are going to write to disk?
Data will not, generally, corrupt in memory and the kernel has no use for the checksums at runtime so we only need to write stuff when it's going to be converted to the on-disk format in ext2_inode_cnv.c.All fields, which are mentioned in SUMMERY, should be written to disk. If it will not be updated, we will have errors reported by e2fsck, or bunch of error messages from driver on linux side.
I am not complaining at all about what is being checksummed: I understand you want to checksum everything that is needed. The main doubt is when to checksum.
There are two possibilities: you either checksum everything as soon as you get it or you checksum at the last moment before writing to disk. Both options have their advantages It seems like the checksumming is happening all over the filesystem so you are doing the former, I was only wondering if we could do all the checksums in a single place, right when we are converting to the ext2fs format for writing.
I am not sure if such thing is poosible though, and your change is not incorrect so I'll let you think about it but I'll approve the patch.
I use second approach, checksum every field before bwrite() call.
OK, I see ...
In D13810#289828, @fsu wrote:In D13810#289543, @pfg wrote:A thought : would it be possible to checksum only what we are going to write to disk?
Data will not, generally, corrupt in memory and the kernel has no use for the checksums at runtime so we only need to write stuff when it's going to be converted to the on-disk format in ext2_inode_cnv.c.All fields, which are mentioned in SUMMERY, should be written to disk. If it will not be updated, we will have errors reported by e2fsck, or bunch of error messages from driver on linux side.
Jan 9 2018
A thought : would it be possible to checksum only what we are going to write to disk?
Data will not, generally, corrupt in memory and the kernel has no use for the checksums at runtime so we only need to write stuff when it's going to be converted to the on-disk format in ext2_inode_cnv.c.
Jan 8 2018
Jan 6 2018
For the record: I never liked adding reallocarray to stdlib.h because it is a nonstandard funtion. In the case of the kernel, of course, I think it is not an issue.