Lines Matching refs:superblock

135 new file_system_type method - kill_sb(superblock).  If you are converting
208 just takes the superblock and inode number as arguments and does the
831 in ->destroy_inode()) is *NOT* ordered wrt superblock destruction;
832 as the matter of fact, the superblock and all associated structures
958 suitable superblock to reuse based on the block device pointer.
960 The new logic tries to find a suitable superblock first based on the device
967 In the old logic concurrent mounters would find the superblock on the list of
969 would hold s_umount they would wait until the superblock became either born or
980 The holder of a block device is now the superblock.
984 superblock without matching on the device pointer stored in the superblock.
986 find the owning superblock of any additional devices.
988 In the old mechanism reusing or creating a superblock for a racing mount(2) and
993     existing superblock was made to wait until the superblock either became
994     ready or until the superblock was removed from the list of superblocks of
995     the filesystem type. If the superblock is ready the caller would simple
999     the superblock had been removed from the list of superblocks of the
1000     filesystem type the mounter would wait until the superblock was shutdown,
1001     reuse the block device and allocate a new superblock.
1004     the superblock had been removed from the list of superblocks of the
1006     superblock (the bd_holder point may still be set to the filesystem type).
1009 mounter could open the block devices of any superblock of the same
1011 still in use by another superblock.
1013 Making the superblock the owner of the block device changes this as the holder
1014 is now a unique superblock and thus block devices associated with it cannot be
1017 superblock.
1019 The new logic thus waits until the superblock and the devices are shutdown in
1020 ->kill_sb(). Removal of the superblock from the list of superblocks of the
1024     superblock is made to wait until the superblock is either ready or until
1025     the superblock and all devices are shutdown in ->kill_sb(). If the
1026     superblock is ready the caller will simply reuse it.
1029     the superblock has been removed from the list of superblocks of the
1030     filesystem type the mounter is made to wait until the superblock and the
1031     devices are shut down in ->kill_sb() and the superblock is removed from the
1033     superblock and grab ownership of the block device (the bd_holder pointer of
1034     the block device will be set to the newly allocated superblock).
1036 (3) This case is now collapsed into (2) as the superblock is left on the list
1038     ->kill_sb(). In other words, if the superblock isn't on the list of
1039     superblock of the filesystem type anymore then it has given up ownership of
1130 superblock of the main block device, i.e., the one stored in sb->s_bdev. Block
1131 device freezing now works for any block device owned by a given superblock, not