On 2016-02-09 at 18:53 +0100, Edward Shishkin wrote: > Hi all, > > There is a pending patch for precise discarsd, which I can not merge > because it is incomplete. Just want to know, is there any progress on > this? > > So we found that calculating discard params by mkfs and storing > them in superblock is a dirty option, so I suggest to reserve a > contiguous area (1 MiB?) on disk at "mkfs -d" time (just mark it busy > in the bitmap). And calculate erase unit size and offset at mount > time. > If calculation failed for some reasons, then use non-precise discard. > > So, I think, we'll need one d32 field in disk superblock, which > indicates > number of reserved blocks (0 means no reservation) and a pair of > definitions in disk_format40.h: > > #define FORMAT40_FIRST_RESERVED_FOR_PROBING \ > ((REISER4_MASTER_OFFSET / PAGE_CACHE_SIZE) + 6) > #define FORMAT40_MAX_BLOCKS_RESERVED_FOR_PROBING > > If any questions, or technical stoppers, then let me know. > > Thanks, > Edward. I guess it would be nicer to allocate the needed space dynamically at mount time. However, there is a problem: where to put the probing code in the fill_super() (I suppose?) sequence? We want the allocator to be intact, but nothing should be written to the filesystem so far. -- Ivan Shapovalov / intelfx / > > > On 07/05/2015 05:13 PM, Ivan Shapovalov wrote: > > > > On 2015-07-05 at 16:06 +0200, Dušan Čolić wrote: > > > > > > On 5 Jul 2015 15:12, "Ivan Shapovalov"<intelfx100@xxxxxxxxx> wro > > > te: > > > > > > > > On 2015-07-05 at 02:33 +0800, Edward Shishkin wrote: > > > > > > > > > > On 07/05/2015 01:53 AM, Ivan Shapovalov wrote: > > > > > > > > > > > > On 2015-07-04 at 15:53 +0800, Edward Shishkin wrote: > > > > > > > > > > > > > > [...] > > > > > > > And how to test directly at mount time? > > > > > > Something along the lines of > > > > > > - allocate 1 MiB of contiguous space > > > > > > - fill it with non-zeros > > > > > > - for N = 1, 2, 4, ...: > > > > > > - discard N sectors from the contiguous space > > > > > > - check if anything in the discarded space became zero > > > > > > -filled > > > > > > - if it did, infer alignnment from the first zero- > > > > > > filled > > > > > > block, > > > > > > infer granularity from the zero-filled region size. > > > > > mkfs seems to be more suitable for this funny business > > > > Yeah, sure. So... new superblock format with two extra fields? > > > > > > > But what happens when someone makes an image of whole partition > > > and > > > uses it > > > on new different ssd? > > Maybe we can make a tunefs.reiser4 (just) for that purpose.
Attachment:
signature.asc
Description: This is a digitally signed message part
